> On Oct 13, 2015, at 8:44 AM, Benson Margulies <[email protected]> wrote: > > I got a lecture on this from Stephen Connolly, who took some time out > from Marathon training to educate me. We're all wrong. > > The only way to 'lock down' a version is to use a range: [foo). All > other versions are 'recommended’.
That is incorrect. I suggest you take a look at the code, or the dependency hierarchy view in M2Eclipse, or the Aether demo code that produces the classpath. With these last two methods you can see what changes in a POM does to the final output. DependencyManagement and scope=import were created to have locked down sets of dependencies for a final product and has worked as such since Maven 2.x. Dependency elements in a dependencyManagement section are internally placed in a map of versionless coordinates with the version. Lets call this the version map. To work in the way it was designed there can only be versions specified within the DependencyManagement section and nowhere else if you want version map to do its job. It’s job is to override all transitive version specifications for a particular coordinate. This is the only way you can have one version of something in a final product. In your transitive closure if you have 7 versions of commons-httpclient they will all be overridden with the version specified in your dependencyManagement section. It assumes you know what you are doing and sometimes you need to hoist up an indirect dependency into the dependencyManagement section to lock it down. This is the only way to have a deterministic build and is what the dependencyManagement feature was created for. Note that anywhere in your product you do specify a version then the dependencyManagement map is not consulted and you fall back to the normal rules of resolution. In the absence of a version being specified the dependencyManagement section is the law for that specified dependency. Again, for anyone who might want to experiment with the how resolution works just load up a project in M2Eclipse and look at the DependencyHierarchy view. It is an unadulterated view of what Aether is doing. Using the Dependency Hierarchy view is how I have always hoisted up errant dependencies in order to lock them down. It is simply the only way to have deterministic product output. There is no heuristic available that can tell you the set of dependencies you have will work together. You have to know your product. Now with better compatibility data you can get pretty close. What the dependencyManagement section is, where no versions are specified anywhere but in the dependencyManagement section, is what in the Eclipse world is called a target platform. Effectively a fully deterministic set of dependencies that are used to build your product. > If there are no ranges, then the resolution algorithm decides what > version to take. It does _not_, contrary to my prior belief, take the > highest version. Instead, it has a tree-topology distance metric to > determine the 'closest' dependency. Also contrary to my understanding, > dependencyManagement does influence this process, it's not merely a > notational convenience. > > So, release asks for 3.0.10, the use of dep-management asks a bit > harder, scm asks for 3.0.15, it loses because it is not nearest. > > I thus conclude that the unpredictable appearance of this bug results > from a process wherein the m-r-p does not always ask SCM to do > something that uses the problem class from 3.0.15. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
