You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org> on 2010/09/07 20:21:33 UTC

[jira] Closed: (MNG-4790) Dependency resolution issue with provided scope

     [ 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