Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-3001

Maven2 does not resolve version ranges correctly [PATCH INCLUDED]

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Duplicate
    • 2.0.4, 2.0.6
    • None
    • None
    • Windows. Affects versions 2.04 & 2.06 minimum.

    Description

      Maven does not properly handle version ranges when the high end is unbounded. The spec clearly states that it should not resolve to a SNAPSHOT unless included as an explicit boundary. Currently maven2 does resolve to a SNAPSHOT which makes usage of version ranges to control versions of dependencies unworkable. (We currently use a local build of maven with this fix else we could not use version ranges. This is a major issue can you please include in the next release?)

      Code fix and unit tests are included.

      Example:

      <dependency>
      <groupId>myGroup</groupId>
      <artifactId>myArtifact</artifactId>
      <version>[1.0,)</version>
      </dependency>

      This version range can resolve to the latest development 1.0-SNAPSHOT. All artifact dependencies should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This should resolve to any released version of 1.1 or higher.

      This document:
      http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
      addressed the requirements for version ranges and stated that "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary". I think this requirement was forgotten when version ranges were implemented.

      I have included a patch for this bug. The fix is in the containsVersion method of VersionRange. I have added tests in VersionRangeTest and DefaultArtifactCollectorTest. All tests in maven pass with this fix.

      Attachments

        1. VersionRangeSnapshotFix.patch
          6 kB
          Dave Hoffer

        Issue Links

          Activity

            dhoffer@xrite.com David Hoffer added a comment -

            The title is wrong in MNG-2978 else it is the same bug.

            dhoffer@xrite.com David Hoffer added a comment - The title is wrong in MNG-2978 else it is the same bug.

            I think the specificiation is wrong.

            [1.0,) should resolve to 1.0, 1.0.1-SNAPSHOT, 1.1-SNAPSHOT, 1.1 and higher (but not 1.0-SNAPSHOT).

            Wheter snapshots are included in resolution shouldn't be specified in the version range, but wheter a snapshot repository is
            declared or not. [1.0,) is a minimum version requirement, so this states that any version higher than or equal to 1.0 should work.

            [1.0,) cannot resolve to 1.0-SNAPSHOT. I added 2 tests in trunk to verify that.

            kenney Kenney Westerhof added a comment - I think the specificiation is wrong. [1.0,) should resolve to 1.0, 1.0.1-SNAPSHOT, 1.1-SNAPSHOT, 1.1 and higher (but not 1.0-SNAPSHOT). Wheter snapshots are included in resolution shouldn't be specified in the version range, but wheter a snapshot repository is declared or not. [1.0,) is a minimum version requirement, so this states that any version higher than or equal to 1.0 should work. [1.0,) cannot resolve to 1.0-SNAPSHOT. I added 2 tests in trunk to verify that.
            dhoffer@xrite.com David Hoffer added a comment -

            Kenney,

            I do not think your description of how this should work is correct. The problem is that your solution is too broad (global) it does not give the user fine enough control over inclusion/exclusion of snapshots.

            Your explanation that 1.1-SNAPSHOT, should be included is the exact problem we need to avoid. Since during the maven release process it will auto generate this version after performing the release of 1.0 the 1.1-SNAPSHOT version is often auto generated and will mistakenly be resolved to in the current maven releases.

            What if I have a project with 10 dependencies all of which use set notation and I want the latest released version. Now I am in active development and I want to include a snapshot of one of these dependencies. With your solution I will need the snapshot repository declared because I do need one snapshot. However I do not want the other 9 to resolve to snapshots. This is unworkable (but I have a solution).

            BTW, the way we use maven it would not offer any benefit to ever resolve to snapshots and it seems dangerous because you could never do a release if it did resolve to a snapshot; it is not clear to me that others would benefit. To me [1.0,) does not imply any snapshots should be found. If you want a snapshot I think you should declare this in the version.

            My proposed solutions are:
            1. Always exclude snapshots, as previously stated and patch/test submitted.
            2. Or, make the inclusion/exclusion of snapshots configurable per dependency. This is the only solution I see if we cannot always exclude snapshots. In the following:

            <dependency>
            <groupId>com.xrite</groupId>
            <artifactId>xrite-colorlib-api</artifactId>
            <version>[1.0,)</version>
            <includeSnapshotsInVersionRange>false</includeSnapshotsInVersionRange>
            </dependency>

            I suggest adding the includeSnapshotsInVersionRange (something like this) tag which will allow me to specify the inclusion/exclusion of snapshots when using set notation.

            3. I suppose this could be a global setting in Settings.xml instead as I do always want the same behavior for all dependencies.

            If we cannot do one if these solutions the set notation version of maven is broken and is not usable for our company. This greatly increases the dependency management complexity as we would have to use fixed versions and rely on other techniques to handle dependency management.

            Dave

            dhoffer@xrite.com David Hoffer added a comment - Kenney, I do not think your description of how this should work is correct. The problem is that your solution is too broad (global) it does not give the user fine enough control over inclusion/exclusion of snapshots. Your explanation that 1.1-SNAPSHOT, should be included is the exact problem we need to avoid. Since during the maven release process it will auto generate this version after performing the release of 1.0 the 1.1-SNAPSHOT version is often auto generated and will mistakenly be resolved to in the current maven releases. What if I have a project with 10 dependencies all of which use set notation and I want the latest released version. Now I am in active development and I want to include a snapshot of one of these dependencies. With your solution I will need the snapshot repository declared because I do need one snapshot. However I do not want the other 9 to resolve to snapshots. This is unworkable (but I have a solution). BTW, the way we use maven it would not offer any benefit to ever resolve to snapshots and it seems dangerous because you could never do a release if it did resolve to a snapshot; it is not clear to me that others would benefit. To me [1.0,) does not imply any snapshots should be found. If you want a snapshot I think you should declare this in the version. My proposed solutions are: 1. Always exclude snapshots, as previously stated and patch/test submitted. 2. Or, make the inclusion/exclusion of snapshots configurable per dependency. This is the only solution I see if we cannot always exclude snapshots. In the following: <dependency> <groupId>com.xrite</groupId> <artifactId>xrite-colorlib-api</artifactId> <version>[1.0,)</version> <includeSnapshotsInVersionRange>false</includeSnapshotsInVersionRange> </dependency> I suggest adding the includeSnapshotsInVersionRange (something like this) tag which will allow me to specify the inclusion/exclusion of snapshots when using set notation. 3. I suppose this could be a global setting in Settings.xml instead as I do always want the same behavior for all dependencies. If we cannot do one if these solutions the set notation version of maven is broken and is not usable for our company. This greatly increases the dependency management complexity as we would have to use fixed versions and rely on other techniques to handle dependency management. Dave
            baerrach Barrie Treloar added a comment -

            Also, snapshots can be in your local repository and will be resolved that way, regardless of whether a remote snapshot repository was declared in the build proces.

            Since they are in the loca repo, if they are included as Kenney suggests, then there is no way to not include them.

            I am happy with the spec only included released versions (which is generally what you want)
            If you want a snapshot version you would be not specifying the version information at all and just pick up the latest from a snapshot repo.

            baerrach Barrie Treloar added a comment - Also, snapshots can be in your local repository and will be resolved that way, regardless of whether a remote snapshot repository was declared in the build proces. Since they are in the loca repo, if they are included as Kenney suggests, then there is no way to not include them. I am happy with the spec only included released versions (which is generally what you want) If you want a snapshot version you would be not specifying the version information at all and just pick up the latest from a snapshot repo.
            markh Mark Hobson added a comment - - edited

            Closed as duplicate of MNG-3092 - see comments in that issue.

            markh Mark Hobson added a comment - - edited Closed as duplicate of MNG-3092 - see comments in that issue.
            dhoffer@xrite.com David Hoffer added a comment -

            Since this issue has been closed you might want to watch/vote for MNG-3092 which replaces it.

            dhoffer@xrite.com David Hoffer added a comment - Since this issue has been closed you might want to watch/vote for MNG-3092 which replaces it.

            People

              markh Mark Hobson
              markh Mark Hobson
              Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: