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" <ssh...@gmail.com> a écrit : > On Tue, Aug 20, 2013 at 3:15 PM, Jörg Schaible <joerg.schai...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
