maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baptiste Mathus ...@batmat.net>
Subject Re: Adding support for new dependency mediation strategy
Date Wed, 21 Aug 2013 09:19:51 GMT
Wondering: is this strategy still gonna choose the newest version specified
even if I specify a version inside my pom? Or is it only gonna be used
between dependencies?

If the latter, I may agree it can be of interest.
But with the first I guess it would get crazy not being able to force the
version to be used.

Cheers
 Le 21 août 2013 01:08, "Phillip Hellewell" <sshock@gmail.com> a écrit :

> On Tue, Aug 20, 2013 at 3:15 PM, Jörg Schaible <joerg.schaible@gmx.de>
> wrote:
> >
> > Can you also tell, why you really want to do this? If you really want
> > "predictability", then use a shared parent, declare all involved
> > dependencies there in a dependencyManagement section and declare your
> direct
> > dependencies without any version. This way you can specify any version
> > explicitly.
>
> We have a shared parent, but we don't use dependencyManagement.
> Although we considered using it, we ultimately decided it would make
> things harder for us.
>
> Until recently we never had to worry about dependency mediation
> because we never allowed any version conflicts (we wrote a plugin to
> fail the build on any version clash).  Now we are wanting to allow it
> with some of our components.
>
> We already have predictability now, and we'll continue to have
> predictability with new mediation strategies, as long as we do it
> right.  Which means it needs to be controlled by a setting in the
> (parent) pom, not in settings.xml that users can tweak.  Also, it is
> important to use the "nearest definition" strategy by default for
> backwards compatibility.
>
> The "nearest definition" is not the be-all end-all best strategy for
> resolving version conflicts.  The "newest version" is a very desired
> strategy.  Failing is a very desired strategy.  Maven will be
> extremely more useful and valuable if it supports these other
> strategies.  Other tools out there like Gradle support different
> strategies (btw, Gradle defaults to "newest").
>
>
> http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:version_conflicts
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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