Maven
  1. Maven
  2. MNG-3092

resolution of version ranges with non-snapshot bounds can resolve to a snapshot version

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.2.x
    • Component/s: Dependencies
    • Labels:
      None
    • Patch Submitted:
      Yes
    • Number of attachments :
      2

      Description

      Contrary to the 2.0 design docs:

      "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary."
      – from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification

      The following is equates to true:

      VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new DefaultArtifactVersion( "1.1-SNAPSHOT" ) )

      The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

      1. MNG-3092.patch
        4 kB
        Mark Hobson
      2. MNG-3092.patch
        2 kB
        Kunalkumar Somani

        Issue Links

          Activity

          Hide
          Richard Vowles added a comment -

          @Sergei - disk space is cheap - and its a build server, so its even cheaper. We do exactly this and have zero problem.

          On your own machine, you want snapshots to be failing your build with the enforcer plugin, that is a warning to your developers that you might be doing something you didn't intend. If you are releasing something that relies on a snapshot, that snapshot should be released first or purged.

          Show
          Richard Vowles added a comment - @Sergei - disk space is cheap - and its a build server, so its even cheaper. We do exactly this and have zero problem. On your own machine, you want snapshots to be failing your build with the enforcer plugin, that is a warning to your developers that you might be doing something you didn't intend. If you are releasing something that relies on a snapshot, that snapshot should be released first or purged.
          Hide
          Sergei Ivanov added a comment -

          If you are making cross-cutting changes across multiple projects, you might want to temporarily allow snapshots locally. Likewise, if you load two dependent projects into an IDE, you typically want one of them to resolve to the other, which effectively means resolving to a snapshot.
          What I am missing is simply a command-line switch that would globally allow or disallow resolution of version ranges to snapshots. That'd have eliminated most of the workarounds that we had to implement.

          Show
          Sergei Ivanov added a comment - If you are making cross-cutting changes across multiple projects, you might want to temporarily allow snapshots locally. Likewise, if you load two dependent projects into an IDE, you typically want one of them to resolve to the other, which effectively means resolving to a snapshot. What I am missing is simply a command-line switch that would globally allow or disallow resolution of version ranges to snapshots. That'd have eliminated most of the workarounds that we had to implement.
          Hide
          Caspar MacRae added a comment -

          @Richard, I don't want to troll but you've said a lot here from your own perspective, which while entirely valid for your own flavour of version ranges, simply does not work for the semantic versioning most people were implementing before this mess began.

          The way it used to work was specified - supporting semantic versioning without any tricks, purging, double repos or otherwise.

          I agree with you completely on changing the specification, at an absolute minimum consistency should be maintained.

          http://semver.org/
          http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

          Show
          Caspar MacRae added a comment - @Richard, I don't want to troll but you've said a lot here from your own perspective, which while entirely valid for your own flavour of version ranges, simply does not work for the semantic versioning most people were implementing before this mess began. The way it used to work was specified - supporting semantic versioning without any tricks, purging, double repos or otherwise. I agree with you completely on changing the specification, at an absolute minimum consistency should be maintained. http://semver.org/ http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
          Hide
          Richard Vowles added a comment -

          Yes @Sergei, however you are releasing that snapshot are you not? If we manage to get this plugin working then it would solve your problem as well, but I certainly wouldn't recommend doing so.

          @Casper - I am just one person speaking up about this. Thats what the argument was - too many people rely on the functionality as it is right now, if you change it, you'll break all these and then they'll come complaining on this ticket and we'll get the reverse.

          Show
          Richard Vowles added a comment - Yes @Sergei, however you are releasing that snapshot are you not? If we manage to get this plugin working then it would solve your problem as well, but I certainly wouldn't recommend doing so. @Casper - I am just one person speaking up about this. Thats what the argument was - too many people rely on the functionality as it is right now, if you change it, you'll break all these and then they'll come complaining on this ticket and we'll get the reverse.
          Hide
          Sergei Ivanov added a comment -

          Well, at the moment releasing a large cross-cutting change requires some self-discipline, because Maven is not really helping us there. The only safeguard we have is a release CI build that will reject any incompatible changes that rely on the latest snapshots. But working with snapshots locally is often the only way to test a large change before slowly committing the changes in the dependency order and feeding them into the release process.

          Show
          Sergei Ivanov added a comment - Well, at the moment releasing a large cross-cutting change requires some self-discipline, because Maven is not really helping us there. The only safeguard we have is a release CI build that will reject any incompatible changes that rely on the latest snapshots. But working with snapshots locally is often the only way to test a large change before slowly committing the changes in the dependency order and feeding them into the release process.

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Mark Hobson
            • Votes:
              100 Vote for this issue
              Watchers:
              95 Start watching this issue

              Dates

              • Created:
                Updated: