Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of sshock@gmail.com designates
 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A37C245B-9ACB-488E-AAFC-B79AB3567B6E@tesla.io>
References: 
 <CA+dWQFos=6a7NtVY_z31yEvjYNKBUF=ZbWaqMXkE_2pTBC_kZg@mail.gmail.com>
 <A37C245B-9ACB-488E-AAFC-B79AB3567B6E@tesla.io>
From: Phillip Hellewell <sshock@gmail.com>
Date: Tue, 20 Aug 2013 09:36:30 -0600
Message-ID: 
 <CA+dWQFrNcv2G2m82LcacT_fYD95Be_nyH8HOptBjtTYKBPRfrw@mail.gmail.com>
Subject: Re: Adding support for new dependency mediation strategy
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=089e0122aa246d287004e462d300

--089e0122aa246d287004e462d300
Content-Type: text/plain; charset=UTF-8

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).

Thanks,
Phillip


On Tue, Aug 20, 2013 at 6:37 AM, Jason van Zyl <jason@tesla.io> 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 <sshock@gmail.com> 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
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Be not afraid of growing slowly, be only afraid of standing still.
>
>  -- Chinese Proverb
>
>
>
>
>
>
>

--089e0122aa246d287004e462d300--