[
http://jira.codehaus.org/browse/MNG-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4790.
----------------------------------
Resolution: Not A Bug
Assignee: Benjamin Bentmann
Actually, this works as intended.
The relevant parts of the dependency graph from your example before conflict
resolution:
{noformat}
org.apache.maven.test:maven-3-dependency-resolution:jar:1.0.0-SNAPSHOT
+- org.jboss.ejb3:jboss-ejb3-core:jar:1.5.0:provided
| +- org.jboss.metadata:jboss-metadata:jar:1.0.4:provided
| (+- org.hibernate:ejb3-persistence:jar:1.0.2.GA:compile - excluded by
jboss-ejb3-core)
+- org.jboss.ejb3:jboss-ejb3-common:jar:1.0.2:compile
+- org.jboss.metadata:jboss-metadata:jar:1.0.4:compile
+- org.hibernate:ejb3-persistence:jar:1.0.2.GA:compile
{noformat}
Note that there are two occurrences of jboss-metadata and one of them having
the dependency on ejb3-persistence surpressed via an exclusion.
Now what happens in the legacy resolution code is that the usual nearest-wins
strategy is abandoned and the second occurrence of jboss-metadata (including
its sub tree) is selected for the resolved tree:
{noformat}
org.apache.maven.test:maven-3-dependency-resolution:jar:1.0.0-SNAPSHOT
+- org.jboss.ejb3:jboss-ejb3-core:jar:1.5.0:provided
+- org.jboss.ejb3:jboss-ejb3-common:jar:1.0.2:compile
+- org.jboss.metadata:jboss-metadata:jar:1.0.4:compile
+- org.hibernate:ejb3-persistence:jar:1.0.2.GA:compile
{noformat}
Hence ejb3-persistence shows up erroneously in the class path.
Just slightly changing your example POM by putting jboss-ejb3-core in compile
scope will radically change the resolved tree:
{noformat}
org.apache.maven.test:maven-3-dependency-resolution:jar:1.0.0-SNAPSHOT
+- org.jboss.ejb3:jboss-ejb3-core:jar:1.5.0:compile
| +- org.jboss.metadata:jboss-metadata:jar:1.0.4:compile
+- org.jboss.ejb3:jboss-ejb3-common:jar:1.0.2:compile
{noformat}
i.e. ejb3-persistence vanishes from the class path. A similar dramatic effect
caused by scopes was recently reported as MNG-4761.
As a last illustration, consider this example:
{noformat}
project
+- a:provided
| \- c:1:provided
| \- x
\- b:compile
\- c:2:compile
\- y
{noformat}
Here, the legacy code will resolve the conflict to:
{noformat}
project
+- a:provided
\- b:compile
\- c:1:compile
\- y
{noformat}
i.e. it will pick the version from the nearest node (i.e. 1) but will actually
use the sub tree from the farthest node (i.e. include y instead of x).
> Dependency resolution issue with provided scope
> -----------------------------------------------
>
> Key: MNG-4790
> URL: http://jira.codehaus.org/browse/MNG-4790
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 3.0-beta-3
> Reporter: Paul Gier
> Assignee: Benjamin Bentmann
> Attachments: pom.xml
>
>
> There is a slight difference in the dependency resolution between
> maven-3-beta-2 and maven-3-beta-3. It seems to be related to the "provided"
> scope, but I'm having some difficulty narrowing down the problem. I've
> attached a POM which demonstrates the problem. Using maven-3-beta-2 the
> ejb3-persistence jar is included in the compile classpath. Using
> maven-3-beta-3, this jar is not included in the compile classpath.
--
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
