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'. 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]
