2. Backward compatibility costs. Virtually none. No previously working
build.xml files will now fail to work after this change is implemented.
This depends on your definition of "work". If work means run to completion without errors, you are correct. If work means produce the same output as before, no. This may translate into a silently appearing 30% increase in download time and network bandwith... If you pay per GB for bandwith this could matter a lot. What happens when the 30% increase in size pushes it over the limit for the media being used to package a product and the user doesn't know why? They probably figure they are accidentally including something in a fileset somewhere...
In some ways this sort of silent, non-error producing behavior change is worse because it is harder to diagnose and fix. Your points are very good and this change might still be a good idea, but I don't think it is a nobrainer and ant should be VERY loud about publicizing this change if it is implemented.
-Gus
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
