[
http://jira.codehaus.org/browse/MNG-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140033#action_140033
]
john.crim edited comment on MNG-2525 at 7/1/08 12:06 AM:
---------------------------------------------------------
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:
{code:xml}
<dependency>
<artifactId>A</artifactId>
<groupId>com.company</groupId>
<version>[1.7-SNAPSHOT,)</version>
</dependency>
{code}
* Project C depends on project B (normal non-range dependency):
{code:xml}
<dependency>
<artifactId>B</artifactId>
<groupId>com.company</groupId>
<version>1.2-SNAPSHOT</version>
</dependency>
{code}
# Project B fails to build when {{A:1.7-SNAPSHOT}} is not in the local
repository. The error message is:
{noformat}
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)
{noformat}
# 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:
{code:xml}
<dependency>
<artifactId>A</artifactId>
<groupId>com.company</groupId>
<version>1.7-SNAPSHOT</version>
</dependency>
{code}
* 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:
{code:xml}
<dependency>
<artifactId>A</artifactId>
<groupId>com.company</groupId>
<version>[1.6,)</version>
</dependency>
{code}
it builds correctly using {{A:1.6}} - but obviously the fixes in 1.7-SNAPSHOT
are missing.
was (Author: john.crim):
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:
{code:xml}
<dependency>
<artifactId>A</artifactId>
<groupId>com.company</groupId>
<version>[1.7-SNAPSHOT,)</version>
</dependency>
{code}
* Project C depends on project B (normal non-range dependency):
{code:xml}
<dependency>
<artifactId>B</artifactId>
<groupId>com.company</groupId>
<version>1.2-SNAPSHOT</version>
</dependency>
{code}
# Project B fails to build when {{A:1.7-SNAPSHOT}} is not in the local
repository. The error message is:
{noformat}
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)
{noformat}
# 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:
{code:xml}
<dependency>
<artifactId>A</artifactId>
<groupId>com.company</groupId>
<version>1.7-SNAPSHOT</version>
</dependency>
{code}
* 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:
{code:xml}
<dependency>
<artifactId>A</artifactId>
<groupId>com.company</groupId>
<version>[1.6,)</version>
</dependency>
{code}
it builds correctly.
> SNAPSHOT dependencies aren't found when repository has 'release' disabled and
> a version range is used
> -----------------------------------------------------------------------------------------------------
>
> Key: MNG-2525
> URL: http://jira.codehaus.org/browse/MNG-2525
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 2.0.4
> Environment: Windows XP, Sun JDK 5.0 Update 7
> Reporter: Nathan Beyer (Apache)
> Priority: Critical
> Fix For: Reviewed Pending Version Assignment
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
