realistically, I think the "right" solutions to most of these issues will require a move to modelVersion 5.0.0... and squaring that circle is the problem we've been munching on for a number of years now...
On 3 October 2013 08:44, Geoffrey De Smet <[email protected]> wrote: > Hi, > > Video with 5 Maven dependency puzzlers - can you answer all 5 correctly? :) > http://parleys.com/play/**5148922b0364bc17fc56ca05<http://parleys.com/play/5148922b0364bc17fc56ca05> > (they just made the video free) > > > *How can maven prevent these unwelcome surprises?* > Watch the video first for context. > Here are some proposals (some of which might be worked on already). > > > Question 1: Different groupId > Support metadata in the repository to state that > - the groupId org.javassist conflicts with the groupId javassist > - the groupId:artifactId org.drools.planner:drools-**planner-core > conflicts with org.optaplanner:optaplanner-**core > - the artifactId foo-beforeSplit conflicts with foo-afterSplit-part1 and > foo-afterSplit-part2 > - the fat jar artifactId weld-se conflicts with the jar weld-se-core > (which contents it duplicates) > > Note: the currently solution "a relocation file" has 2 issues (IIRC): > - works only 1 way (IIRC) > - needs to be created for every version (IIRC) > > > Question 3: Conflict nephews > and Question 4: Conflicting cousins > Support pluggable conflict resolution. > Out-of-the-box, make it easy to switch > from "nearest" (default due to backwards compatibility) > to "lexicographic highest version" > > Question 5: Child with dependencyManagement > That's a bug. > > > With kind regards, > Geoffrey De Smet > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
