On 8/9/06, Mike Perham <[EMAIL PROTECTED]> wrote:
Again, this is because dependency B is not using version ranges but rather forcing a specific version on its downstream dependents.
Ah, but dependency B is a third party library ... and the entire transitive dependency tree for Shale (which is pretty small compared to lots of multi-project environments) has at least 100 such dependencies. Seems to me like evangelizing all those folks to set up proper version ranges in their POMs belongs to the Maven team, not to me whose just an (indirect) "Joe User" for all those packages :-). If A requires a different version, it has to declare that dependency in
order to override the transitive dependency version from B. There's nothing Maven can do when the POM data is incorrect. You need to exclude it or override it.
Yes, there is something Maven could do -- it could reflect the reality that most POMs don't actually do this, and provide developers a workaround that protects them from instabilities caused by the current rules. It could define the version conflict resolution rules such that <dependencyManagement> version declarations in *my* POMs (defined as the one for this project or the explictly declared parent tree) always win over version declarations that come from explicit or transitive dependencies. That way, I can declare in a single parent POM all my version dependency information for *all* my leaf node projects (webapps in my case, but the same principle applies to any environment where you are creating lots of individual artifacts that share a common set of dependencies) without having to tediously edit all of the leaf POMs individually. Craig
