ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Date Thu, 16 Feb 2012 20:08:45 GMT
It has but not for quite a long time. Look in the archives from 2001 to 
2003 for "Mutant"[1] which Conor proposed, and "Myrmidon"[2] which  
Peter Donald proposed back in 2000. You can still find them in the svn 
repository[3], [4].

I think there was so much discussion on a new design of Ant that 
everyone just got exhausted talking about it. As I recall what finally 
brought it to a halt was Costin Manolache saying "Just refactor what you 
have while retaining backward compatibility."

The general agreements that I remember, although I haven't trawled the 
mailing list to find references, were that backward binary compatibility 
could only be broken through an Ant 2.0 release, and that Ant 2.0 should 
do everything in its power to be build file compatible. The thinking 
then was an XSLT file could be provided if necessary although at this 
point I think we could provide an <upgrade-buildfile> task even if it 
just ran an XSLT, should that prove necessary. But I don't think it 
should be required if possible, at least not for several minor releases.

This is a new group of Ant developers, though, and they may make 
different decisions than the ones back then did. If we find volunteers 
willing to step forward to help with the code. I can do the 
infrastructure things like setting up a place to put everything in 
subversion, perhaps in ant/sandbox/{some code name}. Any suggestions? 
All I can think of is pezant or something similarly punny. It could just 
be ant2proposal.

As for whether it is a runtime issue, as far as I know the only problem 
with libraries is the bootstrap build. If Ant 2's bootstrap build is 
done by Ant 1 there is no problem with adding any libraries you want to 
the core of Ant 2. If it is self-hosted then Ant 2 needs to be capable 
of running without any external libraries.

This is why the Ant 1.x codebase has a Java tar and zip and bzip2 
implementation hosted within it, even though Apache Commons has superior 
implementations of all of them. Ant source is distributed in these 
formats so Ant needs a bootstrap way to get at it. Stefan maintains the 
compress AntLib for exactly this reason, so Ant can have access to a 
really good, full featured compression library.


On 2/13/2012 1:30 PM, Mansour Al Akeel wrote:
> interesting info. It looks like the idea of the redesign has been discussed
> a lot in the past.
> Another good point, is to have ant independent of any external libraries.
> However, I am wondering if this applies to run time environment ?
> For example, writing a core ant (mainly build.xml parser), as an osgi
> bundle. And collection of bundles for Javac, Java, Copy,... etc. would:
> 1- be independent of any external libraries and relies on JRE to build.
> 2- allow integration with IDEs.
> 3- allow to compile and build the build system, without a build system (ie,
> using bootstrap). or like you said "self-building".
> Would this be acceptable idea ? A core bundle, and extra bundles for basic
> tasks. A bundle for ivy (maybe). We can even have a bundle to install
> additional bundles remotely....
> And with Java7 NIO the performance will be fine.
> comments ?

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

View raw message