B builds with 2.0, if you use B you should use it with whatever it was
built. I think it's clear that B should use 2.0, or you are not using
the "right" B
On 6/6/07, Patrick Schneider <[EMAIL PROTECTED]> wrote:
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]
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
