On Wed, 23 Jan 2002, Peter Donald wrote: > It is actually realtively easy to get about 80-90% backwards compatability > with most tasks. I actually had this working a while back till it broke gump > builds - it wasn't really complete just a proof of concept. Hence it got > zapped - should be easy to get that support back when we need it. > > However due to the relative porous nature of ant1.x it will be virtually > impossible to support the remaining 10-20% because they directly reference > things in ants core or use deprecated features and so forth. > > And with a somewhat complex XSLT sheet most ant build files will be able to > be auotmagically migrated to ant2 or at least partially migrated.
There are 3 issues here: - build.xml changes. I see absolutely no technical reason for not supporting the current (sort-of) dtd. Yes, HTML sucks, but a html page written 5 years ago will still work. You can extend the build.xml, add new semantics, etc - but I see no reason to remove an existing tag or change the behavior of what works today. - 'normal' task interface/patterns changes. Again, I see no reason for a clean task that works today to not work in ant2. Regardless of the changes in the core impl, having a Task class to wrap the new functionality and provide binary backward compat is not that difficult. For 'special' tasks that use internals - it's their fault, nobody can complain. - internals, core, extensions, etc. That can and should evolve, but I don't understand why it have to be a huge jump instead of a gradual process, and why we are discussing whole core replacements instead of individual features that could be voted and discussed one by one, and added in the current ant. At this point and with the current usage of ant, no 'perfect' design can justify the pain associated with changing the build files and tasks. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
