Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Incomplete
-
3.0.4
-
None
-
None
Description
In some ways this is a rehash of MNG-2496 with a different twist.
We're managing enormous sets of interrelated projects, and producing a coherent product (actually many) from these. We're using a cleanroom environment for builds, which means we're trying to limit the number of versions of any given project in that environment to the ones we're actually trying to ship.
To prevent a situation where a single project version upgrade triggers a massive cascade of rebuilds, we're using dependencyManagement extensively to help us manage the versions of things that go in the product(s).
In unusual cases, projects require a particular plugin-level dependency to enable extra functionality (antrun, for example), or to bring in an artifact handler / archiver (assembly plugin).
These cases represent a leak of our managed dependency set, where version information escapes into individual projects and requires that they be rebuilt each time the dependency version changes...putting us part of the way back into the cascading-updates hell.
It may be unreasonable to allow dependencyManagement to control the NORMAL set of dependencies in the plugin's depgraph...I agree with the conclusion in MNG-2496 100%. HOWEVER, in cases where the project overrides or introduces extra dependencies via <plugin><dependencies/>, we SHOULD allow Maven to manage those dependencies.