For the love of god put this in the wiki. Use it as the start of the
spec.
On 6 Jun 07, at 9:46 PM 6 Jun 07, Kenney Westerhof wrote:
I think it's a matter of scope and ordering.
Some brainstorming on specifying this out to the letter:
> > > | A -> B -> C -> D
> > > |
> > > | C depends on D 1.0
> > > | B has D 2.0 in dependencyManagement, no D in dependencies
> > > |
B uses depMgt to say D has to be 2.0. What for?
1) for poms extending B, to specify a default or override
2) since depMgt also applies to transitive deps, it's to say
'whatever any transitive deps bring in, if they use D, it needs to
be 2.0'.
C depends on D, either by having the version directly in the dep,
or in depmgt, doesn't matter.
C's definition conflicts with B's.
Let's assume none of the poms extend from one another.
Here's the question: while traversing the dependency trail from A
to D, should
earlier depMgt declarations take precedence over later onces?
Maven 2.0.6 inverted the behaviour that was here earlier (depMgt/
deps later in the trail take precedence),
to earlier in the trail overrides later deps (at least that's what
it's supposed to do, afaik).
As C declares a direct dep on D, whereas A nor B do, should we
interpret that as more
strict than a depMgt declaration in A?
There's no concrete solution though. The problems arise because
depMgt is used for 2 things:
1) specifying defaults and overrides for child poms
2) overriding transitive deps
(they seem similar, but when resolving dependencies, the path from
an artifact to such a depMgt
declaration is quite different in both cases:
- in the first case a path orthogonal to the dep trail is taken,
say from D not back to A (the deptrail),
but to X, the parent of D.
- in the second case, the normal dependency trail is followed,
where parent poms are merged as normal.
This is effectively the same path as 1), except _ALSO_ the depMgt
in the dependency trail is
used. here's where the 'merge' problem occurs:
- wheter to use the pom of the artifact (D) itself,
or one of it's parents (which parent gets precedence,
topmost or nearest to D?
- dependency trail (which one gets precedence, nearest to D?)
and ofcourse, we combine those 2 to an even more complex decision
graph.
)
A little picture to illustrate the problem:
P1 P2 (parents)
^ ^ ( ^ = extends)
A -> B -> C ( -> = depends)
Say all of P1, P2, A and B declare both a dependency AND depMgt on
C, all with conflicting values.
So we have 2 versions (the one in the dependency, and the one in
the depMgt) per POM.
We have 4 poms. That makes a total of 8 versions to consider for C.
All possible versions for D are:
Ad|Am|P1d|P1m|Bm|Bd|P2d|P2m.
Choice 1: parent overrides child or vice versa:
P1d|P1m|P2d|P2m
or Ad|Am|Bd|Bm
Choice 2: depMgt overrides a dep or vice versa
P1m|Am|P2m|Bm
or P1d|Ad|P2d|Bd
Choice 3: nearer to A wins, or nearer to C wins
P1m|P1d|Am|Ad
or P2m|P2d|Bm|Bd
The final version is the union of each choice. We have 2^3 = 8
rulesets (same as the number
of versions to consider, but that's a coincidence).
One of the 8 possible choices we can make would be:
choice1(parent) ^ choice2(depMgt) ^ choice3(A) =
{P1d|P1m|P2d|P2m} ^ {P1m|Am|P2m|Bm} ^ {P1m|P1d|Am|Ad} = P1m
(note that I didn't even get into profiles, which adds a 4th
choice, property interpolation order,
which adds another choice, and I probably forget some variables. we
have at least 2^5 = 32 possible
rulesets. Sigh.)
If we make this user configurable, we're really flexible, but also
very deeply
in trouble because of all the weird bugreports we'll be getting.
So, 6 questions:
1) what is the intended behaviour now?
2) do the current implementations handle this properly or do we
still have bugs? (i hope that even if the current impls don't
handle 1), that it at least conforms
to one of the 8 possible rulesets above).
3) What do we want it to be?
4) do we want this user configurable?
5) do we want an extra choice/rule, that depMgt only takes
precedence if there's also
a direct dependency declared?
6) Did I miss anything else?
Thanks for reading this far - it's pretty late, so this is
basically a dd if=/dev/ram0 ;)
-- Kenney
Carlos Sanchez wrote:
but you depend on B, so you want B, not C ;)
On 6/6/07, Patrick Schneider <[EMAIL PROTECTED]> wrote:
Right -- but B has no dependency on D, whereas C does. And C was
builds
with 1.0.
On 6/6/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
---------------------------------------------------------------------
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]
