Here's my list what I'd like to see in the next version of ant. Before doing so I want to take a moment to reflect how successful ant1.4 has become -it is now the standard build tool for java projects, and it has also shown that nearly 10+ month intervals do work as a lifespan of what is now a fairly mature piece of code. We've also just launched ant1.5 at what must be, thanks to everyones efforts but Magesh's most of all, was our most rigorous release process to date.
I fear that Ant is now mature and widely used enough that we will have to sporadically release point versions of ant1.5.x while working on the next version. Which is actually good in a way, it stops people being forced to use beta versions just to fix a bug. Doing so thus gives us a chance to do some radical stuff, though of course gump runs off CVS-head which may be an issue. What do I want to see in terms of task evolution: 1. <hostname>, including nslookup of remote addresses 2. try and get the http tasks to work with httpclient, and so work properly 3. I also want to be able to make soap calls from inside ant; that would be slick for some deployment actions 4. <latex> and <pdflatex> tasks in some optional-latex package 5. get the .NET stuff up to snuff for better wsdl import testing of axis services; better handling of references, multiple source files, support for J#, all in the optional-dotnet package 6. pull in the <CC> tasks from ant-contrib. Even if the tasks are in an optional package, I'd like to reuse the library and defines stuff in the .NET compilers, so the datatypes need to be common. 7. Java1.4 support more broadly, perhaps with an <assertionset> type to describe assertions to enable/disable 8. a better sub build task than current <ant>. We cant change that for compatibility reasons but <subbuild> with forking, better defaults, filesets and the like would be cool. 9. xml schema support. Which means some way of adding local schema URLs to catalogs/dtd mappings 10. Easier to contain ant inside guis. I hate getting optional tasks to work in any GUI ant container, it is always so hard. Underneath all that, I want so say that maybe it is time to move to java1.2 and clean up all our classpath stuff, so that we can move to a good packaged world, get rid of so much classpath confusion, etc. Which means that we move to something called ant2.0 If we spend all our life firefighting 1.x issues, then we will never be able to move to the 2.0 codebase. And so Conor's action, deleting mutant from cvs, has made it clear that there have been multiple protos for 2.0, and yet the main ant branch has been too busy evolving to make any revolutionary jumps. Yet the permanent '2.0' is coming pressure has stopped us evolving ant1.x in ways we'd like, because there is pushback on the 'this wont be 2.0 compatible' theme. Example: Jose-Alberto's antlib proposal. So we are doubly stuck: we arent moving ant to a 2.0 codebase, but the fact that such a migration is planned stops is fixing some things in the 1.x platform. We need to move forward, one way or the other. I'm think we ought to give priority at this early post-1.5 point to decide what the focus of development should be for the next round, simple evolution of ant1.5 or whether this is a good time to sit down and move up to starting on ant2.0 in earnest, maybe using mutant or myrmidion as foundations, or (as Costin suggests), to evolve what we have today, but either way to rework enough of ant to make it better than it currently is. Better in terms of scalability, flexibility and usability, yet still being very backwards compatible with the existing build files. Compatibility is always the issue. With a 2.0 number we can get away with incompatilbities that are obvious and easy to fix, but we should still avoid any subtle incompatibilties that only take time to show up, as users wont catch them. Comments? -Steve -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
