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

Hudson doesn't support Maven2 dependency version ranges

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • maven-plugin
    • None
    • Platform: All, OS: All

      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

          [JENKINS-2787] Hudson doesn't support Maven2 dependency version ranges

          After reading it carefully, it seems not to be the same problem, I skimmed through the issue .
          Mine is just about a Project build with version range, not the automatic downstream builds...
          Sorry about that, I'll read carefully next time .

          Clément Caron added a comment - After reading it carefully, it seems not to be the same problem, I skimmed through the issue . Mine is just about a Project build with version range, not the automatic downstream builds... Sorry about that, I'll read carefully next time .

          kutzi added a comment -

          Confirming that it still doesn't work in Jenkins 1.427

          kutzi added a comment - Confirming that it still doesn't work in Jenkins 1.427

          kutzi added a comment -

          Won't Fix.

          We believe that version ranges are a bad practice by themselves and especially when doing continuous integration.

          See http://jenkins.361315.n4.nabble.com/Any-opinions-on-dependency-version-ranges-support-for-Maven2-3-td3766478.html
          and
          http://stackoverflow.com/questions/7167250/should-maven-dependency-version-ranges-be-considered-deprecated
          for more information.

          Given that this wasn't supported in Jenkins from the beginning and this bug got only 3 votes so far, the feature doesn't seem to be missed so much anyway.

          kutzi added a comment - Won't Fix. We believe that version ranges are a bad practice by themselves and especially when doing continuous integration. See http://jenkins.361315.n4.nabble.com/Any-opinions-on-dependency-version-ranges-support-for-Maven2-3-td3766478.html and http://stackoverflow.com/questions/7167250/should-maven-dependency-version-ranges-be-considered-deprecated for more information. Given that this wasn't supported in Jenkins from the beginning and this bug got only 3 votes so far, the feature doesn't seem to be missed so much anyway.

          That's just nice. In both, you tell your own opinion when "asking a question" (obviously just looking for confirmation), and using that as "documentation" that your WONTFIX is warranted.

          The reason that ranges isn't used more widely (hence keeping the vote-count down), is EXACTLY because so many 3rd party projects sucks with ranges. Thank you for keeping Maven a pain.

          Dennis Krøger added a comment - That's just nice. In both, you tell your own opinion when "asking a question" (obviously just looking for confirmation), and using that as "documentation" that your WONTFIX is warranted. The reason that ranges isn't used more widely (hence keeping the vote-count down), is EXACTLY because so many 3rd party projects sucks with ranges. Thank you for keeping Maven a pain.

          kutzi added a comment -

          I'm sorry that I have an own opinion and that it doesn't match yours.
          I have to admit that I didn't ask the questions as open as I should, but fact is:

          • Dependency ranges are not officially documented until today (based on my - probably opionated - view on what official means)
          • 2 Maven core resp. core plugin committers recommended to not use dependency ranges - at least as they are implemented today
          • there are some unsolved problems with ranges - especially how SNAPSHOTs are handled
          • no one really spoke up and had to say something positive about them - okay except you now
          • they ARE a bad practice when using CI. That's again a opinion, of course
          • 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

          kutzi added a comment - I'm sorry that I have an own opinion and that it doesn't match yours. I have to admit that I didn't ask the questions as open as I should, but fact is: Dependency ranges are not officially documented until today (based on my - probably opionated - view on what official means) 2 Maven core resp. core plugin committers recommended to not use dependency ranges - at least as they are implemented today there are some unsolved problems with ranges - especially how SNAPSHOTs are handled no one really spoke up and had to say something positive about them - okay except you now they ARE a bad practice when using CI. That's again a opinion, of course 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

          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).

          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).

          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.

          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.

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

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

          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 ?

          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 ?

          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.

          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.

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

              Created:
              Updated:
              Resolved: