Ultimately the short answer is who cares what 2.0.x does.
Why?
Because we didn't write the spec first and anything that has been
done has been embodied in code and subject to changes like MNG-1577.
We need a spec, define the behavior and then write to that. Trying to
do anything with 2.0.x or the artifact resolution mechanism as it
stands is a complete waste of time. Decide the behavior amongst
ourselves and then make the new mechanism work that way. I've already
run into a half dozen cases where what I worked on doesn't work
generally and so I'm convinced all that matters is the spec. I have a
technically better implementation at the plexus level but how POMs
are read, where repositories can be injected, how profiles are
injected, at what level and how scopes can change all need to be
nailed down.
It's obvious from just this short thread people have differing opinions.
On 6 Jun 07, at 12:35 PM 6 Jun 07, Joakim Erdfelt 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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
