On 3/16/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
On 3/16/07, John Casey <[EMAIL PROTECTED]> wrote: > If the solution to this situation has been to define the dependency locally > with the version you want, how can having a dependencyManagement section > that works transitively possibly be relevant to those builds? Carlos, how > can this possibly break those builds? not in that case, but this one A -> B -> C -> D 1.0 B inherits dependencyManagement from somewhere with D 2.0 but doesn't depend on D explicitly A gets D 1.0 in 2.0.5 A gets D 2.0 in 2.0.6
Right. Assuming the depMgmt section is coming from A, the patch will resolve D to whatever A's depMgmt says. The workaround pre-patch was to explicitly list D in B. For existing projects in which that has been done, this patch will not affect behavior at all. The benefit to these projects is that they can *remove* the explicit listing in B, and get the same behavior. For existing projects in which the workaround was not used, then I would question two things: - Does the project work as expected? - Do they really care what version of D gets pulled in? If they are not using the work around, it seems to me that the answer to at least one of these would have to be 'No'. And in this case, it doesn't seem like altering the behavior matters much anyway. Patrick
