I'm still not 100% sure that's the case.
I am working from the point of view of Archiva on this.
And in that case, the versioning of the various maven-* artifacts are
important.
I seem to recall that the versions in $MAVEN_HOME/bin/lib always
override what is in the plugins.
But this new shaded distribution of maven client might change that behavior.
I need to do more testing.
- Joakim
Carlos Sanchez wrote:
and the other important thing you raised up is that for the reports to
be right the plugins need to be using 2.0.6 libraries too, or we'll
get different reports than the actual behavior
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]
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
