Maven 2 & 3

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

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-3092 Version ranges with non-snapshot bounds can contain snapshot versions

  • Major - Major loss of function.
  • Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.

Task - A task that needs to be done. MENFORCER-94 Review evaluation of version ranges with regard to inclusion of snapshots

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (3)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: