I guess I am on the fence as to whether 2.0 is the correct version of D for A to get.
While B declares version 2.0 in its depMan section, we can't really be sure of the intention of the developer if there is not a direct dependency on D also listed in B. Maybe B is a parent project to X, Y, & Z -- they need version 2.0 of D, and this is the only reason B lists D in depMan.
From the example project, we can't be sure that B really cares which version
of D it gets, because it has no direct dependency on D. On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
Sorry for the 1950's Horror Movie Catchphrase. I'm just odd like that. ;-) The following has been filed as http://jira.codehaus.org/browse/MNG-3038 and I encourage discussion on this. I was recently working out some discrepancies between what maven client, mpir and archiva show as dependency tree's on some projects, and discovered something. MNG-1577 as discussed isn't done (yet). I created the teeny example project following the example that Carlos described on http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html | What about this use case for transitive dependencyManagement? has been tested? | | A -> B -> C -> D | | C depends on D 1.0 | B has D 2.0 in dependencyManagement, no D in dependencies | | A should get D 2.0 Source for project: http://joakim.erdfelt.com/maven/carlos_transitive_version.tar.gz I found that maven 2.0.6 does not handle this use case. When working on project A, i was expecting to see module D version 2.0 in use, but didn't. Here's what I see in mvn -X clean package of module A. [DEBUG] net.example:A:jar:1.0 (selected for null) [DEBUG] Adding managed depedendencies for net.example:B [DEBUG] net.example:D:jar:2.0 [DEBUG] net.example:B:jar:1.0:compile (selected for compile) [DEBUG] net.example:C:jar:1.0:compile (selected for compile) [DEBUG] net.example:D:jar:1.0:compile (selected for compile) That shows that D:2.0 is identified as being part of depMan. [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' --> [DEBUG] (f) basedir = /home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A [DEBUG] (f) buildDirectory = /home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target [DEBUG] (f) classpathElements = [/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target/classes, /home/joakim/.m2/repository/net/example/D/1.0/D-1.0.jar, /home/joakim/.m2/repository/net/example/B/1.0/B-1.0.jar, /home/joakim/.m2/repository/net/example/C/1.0/C-1.0.jar] [DEBUG] (f) compileSourceRoots = [/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/src/main/java] [DEBUG] (f) compilerId = javac [DEBUG] (f) debug = true That shows that the compiler plugin is using D:1.0 as part of the compiler plugin. This has been reviewed by Carlos and Brian on irc as not implemented correctly on maven client. -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
