Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-2787

Hudson doesn't support Maven2 dependency version ranges

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All

      Description

      When setting up multiple Maven2 projects with the dependencies specified as
      version ranges, Hudson doesn't trigger downstream builds if a built version of a
      dependency matches the version range as specified in the downstream project.

      The above URL points to my mail in the Hudson users list archive. It describes
      the setup I used to detect this defect.

      From the sources: the culprit is in hudson.model.MavenModule, method
      buildDependencyGraph(DependencyGraph), line 355:

      MavenModule src = modules.get(d);

      modules is a HashMap with ModuleDependency objects as the key. All
      ModuleDependency objects in there have a normal version number since they
      represent the version information from the modules themselves.

      On the other hand, the lookup with ModuleDependency 'd' can contain a version
      range as the version string. Since the key lookup in the Hashmap works using the
      equals method of ModuleDependency, even if the range matches according the Maven
      versioning concepts, there will be no match from this lookup.

      I think the best way to solve this is to incorporate the usage of the following
      Maven2 interface and classes:

      org.apache.maven.artifact.versioning.ArtifactVersion
      org.apache.maven.artifact.versioning.DefaultArtifactVersion
      org.apache.maven.artifact.versioning.VersionRange

      The last class has the most interesting method ever:

      VersionRange.containsVersion(ArtifactVersion)

      I'll see if I can find the time to create a patch...

      Ringo

        Issue Links

          Activity

          Hide
          losd Dennis Krøger added a comment - - edited

          First of all, I'm sorry that I was being bitchy, but the way it was WONTFIXed kinda rubbed me the wrong way.

          While we certainly agree that there are problems (and not small ones) with ranges, they are also a major help when having several smaller components, especially in an OSGi context where the compiled and runtime version of the dependency can be different anyway.

          One of the ideas behind sematic versioning is exactly that you "should" be safe, as long as you don't go beyond the current major version, and ranges helps to exploit that, keeping some of Maven's pains manageble.

          To make ranges reproducible, maybe it would be a good idea to add some kind of metadata that stored which final target was used for the build? In that way, the build should be easily reproducible (especially if there was a way to export a fixed-version POM from the metadata to reproduce the build).

          Show
          losd Dennis Krøger added a comment - - edited First of all, I'm sorry that I was being bitchy, but the way it was WONTFIXed kinda rubbed me the wrong way. While we certainly agree that there are problems (and not small ones) with ranges, they are also a major help when having several smaller components, especially in an OSGi context where the compiled and runtime version of the dependency can be different anyway. One of the ideas behind sematic versioning is exactly that you "should" be safe, as long as you don't go beyond the current major version, and ranges helps to exploit that, keeping some of Maven's pains manageble. To make ranges reproducible, maybe it would be a good idea to add some kind of metadata that stored which final target was used for the build? In that way, the build should be easily reproducible (especially if there was a way to export a fixed-version POM from the metadata to reproduce the build).
          Hide
          kutzi kutzi added a comment - - edited

          Dennis, if you want to have this fixed in Jenkins a good way is to adapt the patch (convert it into a Github pull request) to work with the current Jenkins sources.
          Also some general improvements to the patch are needed IMHO. Namely to improve the performance by not iterating over all modules each time and of course adding a unit test to verify the changed behaviour.

          Show
          kutzi kutzi added a comment - - edited Dennis, if you want to have this fixed in Jenkins a good way is to adapt the patch (convert it into a Github pull request) to work with the current Jenkins sources. Also some general improvements to the patch are needed IMHO. Namely to improve the performance by not iterating over all modules each time and of course adding a unit test to verify the changed behaviour.
          Hide
          losd Dennis Krøger added a comment -

          Thanks, I'll probably take a look when we have a hole in the schedule.

          Show
          losd Dennis Krøger added a comment - Thanks, I'll probably take a look when we have a hole in the schedule.
          Hide
          fireplace b p added a comment -

          "Meanwhile, in a secret room a lot closer than you might think."

          Hello kutzi,

          I see your comment "you CAN use Jenkins with dependency ranges. It's just that automatic linking of jobs via SNAPSHOT dependencies doesn't work. Everything else should work fine"

          If I understand correctly, our current project (containing some range dependencies) should be able to be build on jenkins ?

          Cause it's not I get ...
          ..... Failed to collect dependencies for [com.....myjar:myjar:jar:[4.0.0,) (compile)

          (on my machine all is well)

          Am I missing something ?

          Show
          fireplace b p added a comment - "Meanwhile, in a secret room a lot closer than you might think." Hello kutzi, I see your comment "you CAN use Jenkins with dependency ranges. It's just that automatic linking of jobs via SNAPSHOT dependencies doesn't work. Everything else should work fine" If I understand correctly, our current project (containing some range dependencies) should be able to be build on jenkins ? Cause it's not I get ... ..... Failed to collect dependencies for [com.....myjar:myjar:jar:[4.0.0,) (compile) (on my machine all is well) Am I missing something ?
          Hide
          kutzi kutzi added a comment -

          AFAIK, dependency ranges support was added to Jenkins in the last weeks, but I also remember that this triggered some bugs (but more for too eager matching). Sorry, wasn't following this closely.

          If you're having problems with dependency resolution you should ask on the users list which is a much better forum to get help than an issue tracker.

          Show
          kutzi kutzi added a comment - AFAIK, dependency ranges support was added to Jenkins in the last weeks, but I also remember that this triggered some bugs (but more for too eager matching). Sorry, wasn't following this closely. If you're having problems with dependency resolution you should ask on the users list which is a much better forum to get help than an issue tracker.

            People

            • Assignee:
              kutzi kutzi
              Reporter:
              ridesmet Ringo De Smet
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: