Simon Kitching wrote: > ---- "Jörg Schaible" <[EMAIL PROTECTED]> schrieb: >> Simon Kitching wrote: >> >> [snip] >> >>> Personally, I prefer the second because it is clear to all >>> readers that yes a version *is* being specified for this >>> dependency. With the dependencyManagement approach, it isn't >>> clear unless you check the parent pom. However I appear to be >>> in the minority, with many people preferring dependencyManagement. >> >> Because the dependencyManagement also define the version of > the transitive deps (at least it should since M206). > > Good point. Using the <version>$foo</version> approach only > works for direct dependencies; it cannot be used to influence > the selected version for a transitive dependency. > > However if you want dependencyManagement to apply to > transient deps, you would really need to use [x.y] or > [x.y,z.a] version numbers, right?
No, not necessarily, but yes, it depends how the accessed artifacts define their dependencies. As long as no locked versions are used, it will work. > If a pom has a dependencyManagement declaration of > <version>1.0</version> > but some required lib declares a dependency on the same artifact using > <version>[1.2,1.4]</version> > then what will happen? > > I presume that version 1.2 will be used, ie the > dependencyManagement declaration is ignored. If that is true, > then it cannot actually be relied on unless > dependencyManagement uses explicitly locked versions (or ranges). Not sure about this (did not try), but AFAICS Maven bails out, since it cannot resolve the artifact to any version. I think the situation is different building libraries of a framework or a project anyway. In a project you will probably use a project POM with locked versions, while for something like Commons it does not make too much sence. Here every component should define the versions of its deps and probably use version ranges only if it is known that some version is not running with it. However, version ranges seem not to be the most stable feature in M2 currently. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
