Jason van Zyl wrote:
I will work with Patrick to put the old and new in 2.0.x. If it really
comes down to turning it off by default, which would be an immense
shame, then so be it and people will just have to turn it on. We'll
just devise a very easy way to turn it on like a property in the
top-level POM. We can't jump from 2.0.6 to a 2.1 for this.
Jason.
Jason,
I would take the override option off the table.
When I wrote the patch for MNG-1577 I added an override element to the
dependencyManagement element in the pom so backward compatibility could
be preserved. However, I realized later that that change itself would
cause problems. This is because adding anything to the pom really
requires the xsd to be updated. In turn, this should require the version
in the pom to be changed since it would be confusing to make a
modification without updating the xsd version. So in addition to having
to add <override>true</override> you would also have to change your pom
version to something like 4.0.1 and reference a different xsd.
Next in 2.1 presumably this element would be removed, so all the poms
where this was specified might not work any longer. But with so many
poms in a maven repository you can't really do that. 2.1 would be forced
to at least tolerate the element so that the builds would work. Of
course, what would you do in 2.1 if you encountered a pom with
<override>false</override> explicitly specified?
Frankly, this seems worse than breaking compatibility in 2.0.x.
Given that, the only other alternatives seem to be system properties or
adding it to the settings. Neither of these is particularly attractive
because if someone tries to run the build and doesn't know to have the
option set then they will get different build results.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
