Maybe I'm just hitting on a long and already closed discussion...I apologize if that's the case.
The default setting of 'true' for this attribute has always bothered me - from a CM perspective it is a bit of a nightmare when you get things in your cp that you didn't intend to be there.
Perusing the archives a bit, I find a patch proposal from Jay Glanville in late 2000, concerning a revised architecture for the javac task and there he notes his opinion on the subject (default = false). The patch overall seems to later have been committed by Stefan Bodewig, but with the default value set to 'true'.
I see no direct discussion on the subject, except for finding hints here and there - maybe I'm not seeking diligently enough. Nor have I been on the mailing list for but a few hours, so...:-).
But, I expect this simply has to do with backwards compatibility. Is this correct, and there is just no way this will change? Or would it be possible to get this behavior changed? Even though a lot of build files may suddenly break, I figure it would be to the better - I'm sure lots of people would find hidden/unexpected dependencies on XML parsers and such, not to mention us that specifically builds against Ant itself, but may want to use one version to build *with* and another to build *against*. Yes - it's not to terribly hard to set the attribute, but IMHO it 'errs on the wrong side' if you forget it/don't understand the implications.
There are lots of things that are inconsistent & due to backwards compatibility. No, we dont want to change them. do you want to field every bug report that comes in saying we broke their build?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
