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
          David Hoffer added a comment -

          We tried to use version ranges but found it to be impossible to get it to work properly so had to abandon all use of the feature. The 'right' way to fix this is to implement it exactly as the spec says, I've never understood why that is so hard to do.

          Show
          David Hoffer added a comment - We tried to use version ranges but found it to be impossible to get it to work properly so had to abandon all use of the feature. The 'right' way to fix this is to implement it exactly as the spec says, I've never understood why that is so hard to do.
          Hide
          Sergei Ivanov added a comment -

          There is no 'right' way to fix this issue in a sense of choosing one and only one option. Implementing it "as the spec says" will make it totally unusable for other people (including us), who rely on certain aspects of the current behaviour. That is why I am saying that we need a proper solution that will allow a greater degree of configuration. I stand by my opinion that the control of snapshot resolution should be external to the POM. In that way, one could use different resolution strategies in different environments (within IDE, on CI server, for release builds) without the need to make changes to the POM itself. For reference, let me link it back to one of my previous posts here:
          https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=323570&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-323570

          Show
          Sergei Ivanov added a comment - There is no 'right' way to fix this issue in a sense of choosing one and only one option. Implementing it "as the spec says" will make it totally unusable for other people (including us), who rely on certain aspects of the current behaviour. That is why I am saying that we need a proper solution that will allow a greater degree of configuration. I stand by my opinion that the control of snapshot resolution should be external to the POM. In that way, one could use different resolution strategies in different environments (within IDE, on CI server, for release builds) without the need to make changes to the POM itself. For reference, let me link it back to one of my previous posts here: https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=323570&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-323570
          Hide
          Scott Sosna added a comment -

          Yes, you've stated before that the incorrect behavior is a "feature" for you, but in fact it's a backwards-regression "bug" for other and should never have been accepted into the work stream. So regardless of your and other's proposals, until a solution is agreed upon, the incorrect behavior that violates the spec should have been removed years ago; of course, after 7 years it is truly a feature and we are stuck in an unworkable situation.

          My question is what are you going to do when the problem is fixed, evaluates versions based on spec, and likely break your current projects?

          In the meantime, I had someone incorrectly install Maven 3.2.1 today and getting artifacts took substantially longer than with Maven 2.2.1 (not within an IDE).

          Show
          Scott Sosna added a comment - Yes, you've stated before that the incorrect behavior is a "feature" for you, but in fact it's a backwards-regression "bug" for other and should never have been accepted into the work stream. So regardless of your and other's proposals, until a solution is agreed upon, the incorrect behavior that violates the spec should have been removed years ago; of course, after 7 years it is truly a feature and we are stuck in an unworkable situation. My question is what are you going to do when the problem is fixed, evaluates versions based on spec, and likely break your current projects? In the meantime, I had someone incorrectly install Maven 3.2.1 today and getting artifacts took substantially longer than with Maven 2.2.1 (not within an IDE).
          Hide
          David Hoffer added a comment -

          I concur with Scott, once folks start building systems around the 'bug' it makes it really hard to ever fix. It should have been quickly fixed 7 years ago when first discussed. Now I don't have high hopes for a fix ever. I can't speak about the 3.2.1 speed differences, I haven't noticed much of a difference in build speed across Maven versions. I'm currently using 3.0.5. IMHO, the only downside to the upgrade is you loose the ability to turn off timestamped snapshots which just complicates the whole snapshot issue...but that's a different topic.)

          Show
          David Hoffer added a comment - I concur with Scott, once folks start building systems around the 'bug' it makes it really hard to ever fix. It should have been quickly fixed 7 years ago when first discussed. Now I don't have high hopes for a fix ever. I can't speak about the 3.2.1 speed differences, I haven't noticed much of a difference in build speed across Maven versions. I'm currently using 3.0.5. IMHO, the only downside to the upgrade is you loose the ability to turn off timestamped snapshots which just complicates the whole snapshot issue...but that's a different topic.)
          Hide
          Markus KARG added a comment -

          I'd like to subscribe to that. Please lead an active and public discussion on this topic. It feels as if Jason just is ignoring this issue, which is hopefully not the case. So Jason, please chime in, and give us a recap of the work done so far, why this needs seven years, and neither there is a solution, nor a public discussion. If you do not find a solution, at least do not give others the impression that they can rely on you coming up with a solution hence holding back with their ideas due to that.

          Show
          Markus KARG added a comment - I'd like to subscribe to that. Please lead an active and public discussion on this topic. It feels as if Jason just is ignoring this issue, which is hopefully not the case. So Jason, please chime in, and give us a recap of the work done so far, why this needs seven years, and neither there is a solution, nor a public discussion. If you do not find a solution, at least do not give others the impression that they can rely on you coming up with a solution hence holding back with their ideas due to that.

            People

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

              Dates

              • Created:
                Updated: