[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322893#comment-322893
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
@Kunalkumar:
Again, I do not see what the problem is with the parent POM. If I understand it
correctly, Maven always interpolates the project's POM entirely before
attempting to resolve dependencies.
Let's set up the following project structure:
{noformat}
./pom.xml
./child/pom.xml
{noformat}
The POM file contents are below:
{code:lang=xml|title=./pom.xml}
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>parent</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<modules>
<module>child</module>
</modules>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>[3.8.1,4.0)</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
{code}
{code:lang=xml|title=./child/pom.xml}
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>test</groupId>
<artifactId>parent</artifactId>
<version>1.0</version>
</parent>
<artifactId>child</artifactId>
<packaging>jar</packaging>
</project>
{code}
Now change to {{child}} directory and run {{mvn help:effective-pom}}. In the
output you will see:
{code:lang=xml}
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>[3.8.1,4.0)</version>
<scope>test</scope>
</dependency>
</dependencies>
{code}
Note that the range is still there. Now, after the project has been
interpolated (that is, an effective POM has been built), Maven will attempt to
resolve the dependencies. It will apply the same resolution logic to every
dependency range it encounters. If snapshots are disabled in ranges via a
global build-level option/flag, each range will be guaranteedly resolved to the
highest available release version. If snapshots are enabled, we revert to the
current behaviour.
The same principle applies to any transitive dependencies. If project A depends
on project B:2.0, and project B depends on C:[1.0,2.0), then the range is still
resolved using the same build-level resolution strategy. If snapshots in ranges
are allowed for the current build execution, then A ends up depending on e.g.
C:1.1, otherwise it ends up depending on e.g. C:1.2-SNAPSHOT.
The main advantage of the build-level control that I propose is that by
excluding the snapshots from version ranges, the project's direct and
transitive dependencies are guaranteedly resolved to release versions only,
with the two exceptions below.
With snapshots in ranges turned off, there are only two ways that the project's
dependency can resolve to a snapshot:
# project A depends on B:1.0.2-SNAPSHOT explicitly. In this case there is no
range definition, and there is no error.
# for example, B:[1.0,2.0) contains only 1.0.0-SNAPSHOT and 1.0.1-SNAPSHOT, and
the range does not resolve to any release version. This must trigger a build
error (unresolved dependency) if snapshots in ranges are disabled.
> Version ranges with non-snapshot bounds can contain snapshot versions
> ---------------------------------------------------------------------
>
> Key: MNG-3092
> URL: https://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Reporter: Mark Hobson
> Assignee: Jason van Zyl
> Fix For: 3.1.1
>
> Attachments: MNG-3092.patch, MNG-3092.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
