maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Hellewell <>
Subject Re: Adding support for new dependency mediation strategy
Date Tue, 20 Aug 2013 15:36:30 GMT
Thanks everyone for you help so far.

So would the crux of this be to create a VersionSelector class called
NewestVersionSelector, and then find the code where it is currently
hard-coded to use NearestVersionSelector and make it possible to use this
one instead?

Yeah, I'm also very concerned about the issue of predictability, and also
of preserving existing behavior.  You know, I don't think I can guarantee
predictability if I have a setting in settings.xml, because individual
users could tweak that.  I believe the behavior needs to be defined in the
parent pom, e.g., in a new tag called <dependencyMediationManagement> or
something (help me think of a good name).


On Tue, Aug 20, 2013 at 6:37 AM, Jason van Zyl <> wrote:

> Aether is incredibly flexible and can pretty much do anything. The class
> that Olivier pointed you at is the where the Maven rules are encapsulated.
> The issue is interoperability in the behaviour of a new Maven that may do
> something different and versions of Maven that don't. Selecting the nearest
> provides one type of predictability but is more focused on the users direct
> POM. Selecting the latest provides another type of predictability but
> almost certainly a completely different result.
> If everyone building a project used the same version of Maven it can work.
> Even on the outside world for a public OSS project you can enforce the
> version of Maven and it can potentially work. As with almost everything we
> talk about with respect to new POM elements or new behaviour is a matter of
> how much we want to preserve existing behaviour and interoperatilbity.
> On Aug 19, 2013, at 11:11 AM, Phillip Hellewell <> wrote:
> > Hi all,
> >
> > I'd like to take a stab at adding support for Maven to be able to mediate
> > dependency conflicts using "highest version" strategy rather than
> "nearest
> > definition".
> >
> > I'll be happy if anyone can point me in the right direction on which
> source
> > files I'll need to modify, and any other guidance.  Also, how long do you
> > expect such a task would take for a competent developer?
> >
> > Finally, I'm curious to know what are the chances of a patch being
> accepted
> > when I'm done?  I'll of course do it in such a way that the default
> remains
> > "nearest definition", and this new strategy has to be enabled with a
> > setting in settings.xml or something.
> >
> > Thanks,
> > Phillip Hellewell
> Thanks,
> Jason
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> ---------------------------------------------------------
> Be not afraid of growing slowly, be only afraid of standing still.
>  -- Chinese Proverb

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message