ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: what I want to see in the next version of ant
Date Mon, 22 Jul 2002 20:18:17 GMT
Not a comment, just a reminder ;-)

11. The <spawn> task to 'start and forget' a process.

Thanks for trying to un-stuck the current situation... --DD

-----Original Message-----
From: Steve Loughran [] 
Sent: Monday, July 22, 2002 3:09 PM
To: ant
Subject: what I want to see in the next version of ant

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

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

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.



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message