I wanted to get some feedback first, flesh it out on the dev list and then jot it down. Need some feedback as to how it's supposed to work now and what we want.
If there's no response within a reasonable amount of time I'll just put it in the wiki. Thanks, Kenney Jason van Zyl wrote:
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 override2) 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, shouldearlier 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 morestrict 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 depMgtdeclaration 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 isused. 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|BdThe final version is the union of each choice. We have 2^3 = 8 rulesets (same as the numberof 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 possiblerulesets. Sigh.)If we make this user configurable, we're really flexible, but also very deeplyin 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 conformsto 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 alsoa 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 buildswith 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
