You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Joakim Erdfelt <jo...@erdfelt.com> on 2007/06/07 04:10:12 UTC
IT0121 - was ( Re: Dawn of the MNG-1577 )
I created an core integration test with an albeit contrived example of
the A -> B -> C -> D use case.
See it0121, it's commit'd
- Joakim
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 <ps...@gmail.com> 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 <ca...@apache.org> 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 <ps...@gmail.com> 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 <jo...@erdfelt.com> 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
>>> > > > joakim@erdfelt.com
>>> > > > Open Source Software (OSS) Developer
>>> > > >
>>> > > >
>>> > > >
>>> ---------------------------------------------------------------------
>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>> > > >
>>> > > >
>>> > >
>>> >
>>> >
>>> > --
>>> > I could give you my word as a Spaniard.
>>> > No good. I've known too many Spaniards.
>>> > -- The Princess Bride
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
- Joakim Erdfelt
joakim@erdfelt.com
Open Source Software (OSS) Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org