> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]
> deprecation does not imply that we are removing the > functionality. Just that > it is unsafe, unsupported whatever or perhaps we just prefer > you write build > files like this rather than that. http://java.sun.com/j2se/1.3/docs/guide/misc/deprecation/deprecated.html " Valid reasons for wishing one's users to migrate to the new API include: the old API is insecure, buggy, or highly inefficient the old API is going away in a future release the old API encourages very bad coding practices " > Similar to the way that in the jdk, the unsafe stuff or stuff > that violated > later developed conventions (ala the bean spec) was marked as > deprecated but > has yet to be removed. Of course. We don't have the same business decision. How do you want Sun to communicate on backward compatibility, portability and such if they break the API ? They are walking on eggs here. > If the XSLT file can be made safe enough then that may be an > option. But The file is committed as ant-update.xsl, so you can remove your -1 :-) > unless there is a real engineering reason for removing backwards > compatability in ant1.x then I would -1. While I fully understand the reasons, there is a balance between doing nothing and removing for fun to give a contribution to the world entropy. Your previous statement about the fact that people are still using a tomcat version of whatever and would like to upgrade to the latest and everything works fine is not a valid one to me for a simple reason. If they decide to upgrade in 10 years that does not mean we should not remove them within 10 years... the human nature is lazy by essence so if something works and we are using 0.1% of its features there are not much reasons to upgrade except the fun of upgrading. Additionaly the example of Exolab is not a valid one either since Stefan asked them to upgrade Ant (AdaptX task)... and as you can see in the user list there are many shops that use a recent version of Ant... and some are even in the CVS version apparently... Our chance is that the build file is XML therefore it should be piece of cake to transform a tag into another...right ? :-) Stephane -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
