ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: what I want to see in the next version of ant
Date Mon, 22 Jul 2002 20:55:11 GMT

I prefer to have 1.6 as the next release, but I can live with calling
it 2.0.

My only ( very strong ) requirement is that each change must make 
the best possible efforts to preserve compatibility with 1.5, 
and each individual change must be aproved by majority vote. 
And I would certainly opose replacing the entire codebase or
making arbitrary changes just because we call it 2.0. 

Each ant release ( starting with 1.0 ) made changes - while 
officially trying to be as backward compatible as possible. 
I don't think that 'allow top-level tasks' or 'classloader fixes'
or 'import' or 'antlib' or 'sax2' or 'jdk1.2' would 
require a 2.0 name, but I agree that maybe the combination
of all those may fit the label.

On the other side, I believe ( and ProjectHelper should prove it
if you don't want to believe me ) that even 1.5 can support most
of those new features. It would be much better to provide
them now, as 1.5 'add-ons' and gather user feedback on each - 
and use this in 1.6/2.0/whatever.

In any case, the name of the next release and the content 
must be determined by vote - and until a release plan is voted
we should continue with the work on the main branch and make
proposals/vote for each major change.


On Mon, 22 Jul 2002, Steve Loughran wrote:

> 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:   <>
> For additional commands, e-mail: <>

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

View raw message