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
          ridesmet Ringo De Smet added a comment -

          Created an attachment (id=497)
          Initial cut at support for Maven2 dependency version ranges

          Show
          ridesmet Ringo De Smet added a comment - Created an attachment (id=497) Initial cut at support for Maven2 dependency version ranges
          Hide
          ridesmet Ringo De Smet added a comment -

          Koshuke,

          I attached an initial version of a patch supporting Maven2 dependency version
          ranges. I took the shortest path possible as you can probably see. However, it
          doesn't work completely as expected and I need a bit of input here.

          My Hudson test setup has the same set of Maven2 projects setup twice. Once in a
          normal way with the dependency version ranges, and once via an active profile,
          specified in the Maven2 goals and options field (-P the-profile). The profile
          redefines the version property to become a SNAPSHOT-to-SNAPSHOT dependency chain
          between all modules.

          With the patch applied, my Hudson Maven module for pres.d:9.10.2 (a released
          version) eventually gets "app.d 9.10" and "app.d 9.10.x" as downstream
          dependencies. The former app.d is the one with the active profile, which I
          expect not to match since the dependency should be 9.10-SNAPSHOT and not the
          version range.

          Now my question: where are the active profiles taken into account when building
          the dependency graph? It seems to work for the SNAPSHOT-to-SNAPSHOT dependency
          chain...

          Ringo

          Show
          ridesmet Ringo De Smet added a comment - Koshuke, I attached an initial version of a patch supporting Maven2 dependency version ranges. I took the shortest path possible as you can probably see. However, it doesn't work completely as expected and I need a bit of input here. My Hudson test setup has the same set of Maven2 projects setup twice. Once in a normal way with the dependency version ranges, and once via an active profile, specified in the Maven2 goals and options field (-P the-profile). The profile redefines the version property to become a SNAPSHOT-to-SNAPSHOT dependency chain between all modules. With the patch applied, my Hudson Maven module for pres.d:9.10.2 (a released version) eventually gets "app.d 9.10" and "app.d 9.10.x" as downstream dependencies. The former app.d is the one with the active profile, which I expect not to match since the dependency should be 9.10-SNAPSHOT and not the version range. Now my question: where are the active profiles taken into account when building the dependency graph? It seems to work for the SNAPSHOT-to-SNAPSHOT dependency chain... Ringo
          Hide
          kutzi kutzi added a comment -

          Hmm, this is rather old and a lot has changed in the maven plugin in the mean time.

          Is this still a problem with current Jenkins versions?

          Show
          kutzi kutzi added a comment - Hmm, this is rather old and a lot has changed in the maven plugin in the mean time. Is this still a problem with current Jenkins versions?
          Hide
          ccaron Clément Caron added a comment -

          Hello,

          I still have the problem with the current version of Jenkins, the range works well on my computer using only maven, but doesn't work on my server using Jenkins.

          Any news about this issue ?

          Show
          ccaron Clément Caron added a comment - Hello, I still have the problem with the current version of Jenkins, the range works well on my computer using only maven, but doesn't work on my server using Jenkins. Any news about this issue ?
          Hide
          kutzi kutzi added a comment -

          No, not yet.

          I'll have a look at the patch, but I cannot make any promises on the timeframe.

          Show
          kutzi kutzi added a comment - No, not yet. I'll have a look at the patch, but I cannot make any promises on the timeframe.
          Hide
          ccaron Clément Caron added a comment -

          In fact, it depends of the build plugin I think...
          On my Jenkins, poms build with maven-assembly-plugin works fine with version range, but those using maven-petals-plugin don't. I'm looking if there is an issue about version range compatibilities with maven-petals-plugin.

          Show
          ccaron Clément Caron added a comment - In fact, it depends of the build plugin I think... On my Jenkins, poms build with maven-assembly-plugin works fine with version range, but those using maven-petals-plugin don't. I'm looking if there is an issue about version range compatibilities with maven-petals-plugin.
          Hide
          kutzi kutzi added a comment -

          Clément, this issue is about the automatic job dependency detection in Jenkins based on the POMs and not about some general build problems. Are you sure, we are talking about the same problem?
          Or asked otherway: what is your concrete problem with the dependency ranges?

          Show
          kutzi kutzi added a comment - Clément, this issue is about the automatic job dependency detection in Jenkins based on the POMs and not about some general build problems. Are you sure, we are talking about the same problem? Or asked otherway: what is your concrete problem with the dependency ranges?
          Hide
          ccaron 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 .

          Show
          ccaron 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 .
          Hide
          kutzi kutzi added a comment -

          Confirming that it still doesn't work in Jenkins 1.427

          Show
          kutzi kutzi added a comment - Confirming that it still doesn't work in Jenkins 1.427
          Hide
          kutzi 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.

          Show
          kutzi 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.
          Hide
          losd 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.

          Show
          losd 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.
          Hide
          kutzi 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
          Show
          kutzi 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
          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: