Maven 2 & 3

SNAPSHOT dependencies aren't found when repository has 'release' disabled and a version range is used

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Duplicate
  • Affects Version/s: 2.0.4
  • Fix Version/s: None
  • Component/s: Dependencies
  • Labels:
    None
  • Environment:
    Windows XP, Sun JDK 5.0 Update 7
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

When a repository is configured (POM, profiles, etc), 'releases' is disabled, 'snapshots' is enabled and a dependency uses a version range, the dependency fails to resolve. The dependency is found when an explicit version is used. The following can be used to recreate the issue.

Setup the maven snapshot repository in an active profile like this:

<repository>
<id>apache.snapshots</id>
<name>Maven Snapshots</name>
<url>http://people.apache.org/maven-snapshot-repository</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>

Check out the maven-install-plugin at revision 427494 (or any revision or other plugin that has a dependency that's a SNAPSHOT). Run a build (mvn package) and all dependencies should download. Modify the dependency in the POM to use a version range, instead of an explict version. For example, change the version "1.0-SNAPSHOT" to "[0,1)", which includes the same version. Run another build (mvn package) and the dependency will fail to download.

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. MNG-2994 Snapshot repositories are not checked when using ranges

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-3376 plugin repositories are not checked when looking for snapshot plugin.

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

Bug - A problem which impairs or prevents the functions of the product. MNG-2126 Snapshot plugin repositories are not searched for plugins that do not explicitly specify a snapshot version.

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

I'm sure that this has been filed elsewhere - would be worth checking for dupes.

Show
Brett Porter added a comment - I'm sure that this has been filed elsewhere - would be worth checking for dupes.
Hide
Permalink
Nathan Beyer (Apache) added a comment -

I scanned and searched the issues under "Dependencies" and didn't find anything that seemed similar. I'll do another search and see if I find something.

Show
Nathan Beyer (Apache) added a comment - I scanned and searched the issues under "Dependencies" and didn't find anything that seemed similar. I'll do another search and see if I find something.
Hide
Permalink
Nathan Beyer (Apache) added a comment -

MNG-2126 seems similiar and there's a comment about it being a duplicate, but I didn't see any indication of the original issue.

Show
Nathan Beyer (Apache) added a comment - MNG-2126 seems similiar and there's a comment about it being a duplicate, but I didn't see any indication of the original issue.
Hide
Permalink
John Crim added a comment - - edited

We have a similar problem - this is the only issue I could find that mostly describes the symptoms we're seeing:

  • We have internal corporate snapshot and release repositories for our internal projects. The snapshot repository only contains snapshots, and the release repository only contains releases. Both repositories contain the same internal projects (groupIds and artifactIds).
  • In our default profile, the release repository is listed before the snapshot repository - hence the release repository is always searched first.
  • Project B depends on project A like so: 
    <dependency>
  <artifactId>A</artifactId>
  <groupId>com.company</groupId>
  <version>[1.7-SNAPSHOT,)</version>
</dependency>
  • Project C depends on project B (normal non-range dependency): 
    <dependency>
  <artifactId>B</artifactId>
  <groupId>com.company</groupId>
  <version>1.2-SNAPSHOT</version>
</dependency>
  1. Project B fails to build when A:1.7-SNAPSHOT is not in the local repository. The error message is: 
    Couldn't find a version in [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6] to match range [1
.7-SNAPSHOT,)
  com.company:A:jar:null

from the specified remote repositories:
  internal.snapshots (http://build01-hq:8082/snapshots),
  central (http://build01-hq:8080/archiva/repository/proxy),
  internal.release (http://build01-hq:8082/releases)
  2. Project C fails to build when project A is not in the local repository. The error message is the same.
  3. Both (1) and (2) work correctly when A:1.7-SNAPSHOT is in the local repository.
  4. This result for (2) doesn't change even if project C defines an explicit dependency on A that matches the range restriction, like: 
    <dependency>
  <artifactId>A</artifactId>
  <groupId>com.company</groupId>
  <version>1.7-SNAPSHOT</version>
</dependency>
  • It appears that the metadata in our snapshot repository is never searched when the range is resolved.
  • If the version range is changed to a release version, the range is correctly resolved. In other words, if project B's dependency on project A is changed to: 
    <dependency>
  <artifactId>A</artifactId>
  <groupId>com.company</groupId>
  <version>[1.6,)</version>
</dependency>

    it builds correctly using A:1.6 - but obviously the fixes in 1.7-SNAPSHOT are missing.

Show
John Crim added a comment - - edited We have a similar problem - this is the only issue I could find that mostly describes the symptoms we're seeing: We have internal corporate snapshot and release repositories for our internal projects. The snapshot repository only contains snapshots, and the release repository only contains releases. Both repositories contain the same internal projects (groupIds and artifactIds). In our default profile, the release repository is listed before the snapshot repository - hence the release repository is always searched first. Project B depends on project A like so: <dependency> <artifactId> A </artifactId> <groupId> com.company </groupId> <version> [1.7-SNAPSHOT,) </version> </dependency> Project C depends on project B (normal non-range dependency): <dependency> <artifactId> B </artifactId> <groupId> com.company </groupId> <version> 1.2-SNAPSHOT </version> </dependency> Project B fails to build when A:1.7-SNAPSHOT is not in the local repository. The error message is: Couldn't find a version in [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6] to match range [1 .7-SNAPSHOT,) com.company:A:jar:null from the specified remote repositories: internal.snapshots (http://build01-hq:8082/snapshots), central (http://build01-hq:8080/archiva/repository/proxy), internal.release (http://build01-hq:8082/releases) Project C fails to build when project A is not in the local repository. The error message is the same. Both (1) and (2) work correctly when A:1.7-SNAPSHOT is in the local repository. This result for (2) doesn't change even if project C defines an explicit dependency on A that matches the range restriction, like: <dependency> <artifactId> A </artifactId> <groupId> com.company </groupId> <version> 1.7-SNAPSHOT </version> </dependency> It appears that the metadata in our snapshot repository is never searched when the range is resolved. If the version range is changed to a release version, the range is correctly resolved. In other words, if project B's dependency on project A is changed to: <dependency> <artifactId> A </artifactId> <groupId> com.company </groupId> <version> [1.6,) </version> </dependency> it builds correctly using A:1.6 - but obviously the fixes in 1.7-SNAPSHOT are missing.
Hide
Permalink
Kees van Dieren added a comment -

Ranges should not lead to snapshot dependencies, unless a snapshot is explicit specified in the version range.
See: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
Quote: "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary"

Show
Kees van Dieren added a comment - Ranges should not lead to snapshot dependencies, unless a snapshot is explicit specified in the version range. See: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution Quote: "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary"

People

  • Assignee:
    Brett Porter
    Reporter:
    Nathan Beyer (Apache)
Vote (5)
Watch (7)

Dates

  • Created:
    Updated:
    Resolved: