Maven
  1. Maven
  2. MNG-4751

Snapshot version not resolved for version range

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.0-beta-1
    • Fix Version/s: 3.0
    • Component/s: Dependencies
    • Labels:
      None
    • Environment:
      linux x86_64, sun java 1.6.0_14
    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      Even with a snapshot dependency in the pom, a release version is included in the classpath for compilation.

      This happens when a mid-level dependency and the top-level project both depend on the same artifact. The mid-level dependency selects a range of valid versions which includes the snapshot version and the top-level project depends explicitly on the snapshot version.

      This is a regression from 2.2.1

      To reproduce:
      1. Release/deploy/install v1.0 of tlib
      2. deploy v1.1-SNAPSHOT of tlib
      3. Release/deploy/install v1.0 of tlib2
      4. Try to compile tapp

        Issue Links

          Activity

          Hide
          Brian Kramer added a comment -

          I found a workaround, I'm not sure that this is the intended behavior but if you make the snapshot a single inclusive range then it works.

          in tapp/pom.xml:
          <dependency>
          <groupId>org.tlib</groupId>
          <artifactId>tlib</artifactId>
          <version>[1.1-SNAPSHOT]</version>
          </dependency>

          Show
          Brian Kramer added a comment - I found a workaround, I'm not sure that this is the intended behavior but if you make the snapshot a single inclusive range then it works. in tapp/pom.xml: <dependency> <groupId>org.tlib</groupId> <artifactId>tlib</artifactId> <version> [1.1-SNAPSHOT] </version> </dependency>
          Benjamin Bentmann made changes -
          Field Original Value New Value
          Link This issue is related to MNG-3092 [ MNG-3092 ]
          Benjamin Bentmann made changes -
          Summary Snapshot version not resolved Snapshot version not resolved for version range
          Hide
          Benjamin Bentmann added a comment -

          This was an intentional change to fix MNG-3092. The new behavior is apparently as controversial as the previous one, so feel free to join the related discussion Resolving SNAPSHOTs from Version Ranges in Maven 3

          Show
          Benjamin Bentmann added a comment - This was an intentional change to fix MNG-3092 . The new behavior is apparently as controversial as the previous one, so feel free to join the related discussion Resolving SNAPSHOTs from Version Ranges in Maven 3
          Hide
          Mark Derricutt added a comment -

          This now seems to be affecting IntelliJ IDEA as well ( at least I suspect this might be the reason ), as the IDE's maven support now resolves all project artifacts to the released version, rather than the -SNAPSHOT version in the opened project, which means you get the annoying behavior of single stepping into, and breakpoints stopping on .class entries from a jar file rather than the .java file in our source paths.

          As mentioned in MNG-3092 - I love this feature FOR RELEASES where I wholeheartedly only want to resolve released artifacts so that any API breakages are caught that otherwise might leak in without a proper version bump ( 1.2.4 -> 1.3.1 for instance ) - but for integration tests, distribution builds, and IDE integration I think having the old behavior is preferred.

          Off by default would be fine by me, as long as I can enable it for projects that explicitly say "give me the bleeding edge", possibly via a POM element ( schema breaking tho ), a plugin configuration, or just a system property that one needs to set.

          I was pointed at http://youtrack.jetbrains.net/issue/IDEA-25146 yesterday (IntelliJ bug report) for some maven resolution oddities which I commented on about this range issue, however they may or may not be related.

          Show
          Mark Derricutt added a comment - This now seems to be affecting IntelliJ IDEA as well ( at least I suspect this might be the reason ), as the IDE's maven support now resolves all project artifacts to the released version, rather than the -SNAPSHOT version in the opened project, which means you get the annoying behavior of single stepping into, and breakpoints stopping on .class entries from a jar file rather than the .java file in our source paths. As mentioned in MNG-3092 - I love this feature FOR RELEASES where I wholeheartedly only want to resolve released artifacts so that any API breakages are caught that otherwise might leak in without a proper version bump ( 1.2.4 -> 1.3.1 for instance ) - but for integration tests, distribution builds, and IDE integration I think having the old behavior is preferred. Off by default would be fine by me, as long as I can enable it for projects that explicitly say "give me the bleeding edge", possibly via a POM element ( schema breaking tho ), a plugin configuration, or just a system property that one needs to set. I was pointed at http://youtrack.jetbrains.net/issue/IDEA-25146 yesterday (IntelliJ bug report) for some maven resolution oddities which I commented on about this range issue, however they may or may not be related.
          Herve Boutemy made changes -
          Link This issue is related to MENFORCER-94 [ MENFORCER-94 ]
          Hide
          Herve Boutemy added a comment -

          please have a look at http://docs.codehaus.org/display/MAVENUSER/SNAPSHOT+Resolution

          if the use case given by Brian is correct, we should transform it as a maven-aether-provider unit test and work on a fix (doing a fork of Maven in github should be ok to have everybody make personal tests)

          Show
          Herve Boutemy added a comment - please have a look at http://docs.codehaus.org/display/MAVENUSER/SNAPSHOT+Resolution if the use case given by Brian is correct, we should transform it as a maven-aether-provider unit test and work on a fix (doing a fork of Maven in github should be ok to have everybody make personal tests)
          Hide
          Benjamin Bentmann added a comment -

          FYI, I sent a proposal to the dev thread Re: snapshot range changes in m3, feedback appreciated.

          Show
          Benjamin Bentmann added a comment - FYI, I sent a proposal to the dev thread Re: snapshot range changes in m3 , feedback appreciated.
          Hide
          Benjamin Bentmann added a comment -

          Fixed in r997380 by reverting the change for MNG-3092 until a more robust solution is designed.

          Show
          Benjamin Bentmann added a comment - Fixed in r997380 by reverting the change for MNG-3092 until a more robust solution is designed.
          Benjamin Bentmann made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Benjamin Bentmann [ bentmann ]
          Fix Version/s 3.0-beta-4 [ 16712 ]
          Resolution Fixed [ 1 ]
          Benjamin Bentmann made changes -
          Fix Version/s 3.0 [ 13142 ]
          Fix Version/s 3.0-beta-4 [ 16712 ]

            People

            • Assignee:
              Benjamin Bentmann
              Reporter:
              Brian Kramer
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: