The email from Jason below explains why it was done this way. I believe
this discussion should have happened on the dev list.
Ralph
Brett Porter wrote:
This was something I specifically wanted to check, so I'll look more
closely in the next couple of days, but it sounds like a deal breaker
for a .0.x release.
- Brett
Jason van Zyl wrote:
On 14 Jan 07, at 3:26 PM 14 Jan 07, Ralph Goers wrote:
Actually, IMO it does add semantic content.
But I think we've decided the current behavior should not exist. That
we want to replace it because it's wrong. If that's true then I would
prefer not to introduce anything into the POM for it.
Without it being in the pom different people running the build would
get different results, unless they also have the property set.
Yes, but both options will not exist in 2.1. I just want the right
way. In 2.0.x it's use will be exceptional and should be noted.
Would anyone using 2.1 ever want the old behavior? I think people just
generally work around what is really a problem.
The way I anticipated it for 2.0.x, if the override element is not
present (or is set to false) it should behave exactly as it does
without the patch. It would be extremely easy for the override to
default to true in 2.1
Let's work on the different implementations and we'll go to the list
to see how people think it should be activated.
Jason.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
