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 <ssh...@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
