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
