ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: What is going on in ANT1.x
Date Sun, 10 Feb 2002 07:26:29 GMT

> -----Original Message-----
> From: Magesh Umasankar []
> Sent: Sunday, 10 February 2002 5:03 AM
> To: Ant Developers List
> Subject: Re: What is going on in ANT1.x
> From: "Steve Loughran" <>
> > True, but I have also seen a lot of bugreps
> > dealt with by saying "download the nightly
> > build"; some people may be forced to upgrade
> > for bug fix reasons
> There have been numerous messages in ant-user
> also where using a nightly build was suggested
> as the alternative.  So my questions are:
> 1. Are these hints for us to get another
> release out the door?
> 2. Do we have any major feature addition
> in mind for Ant 1.5?  If so, what are they?

There's 2 things I'd like to do, if I find time.  Nothing worth holding up a
release for, though.

* Include the <cc> task as an experimental task.  I don't think the task
interface is quite right yet, so it would be too early to include it as an
'official' task and freeze the interface.  However, the best way to get the
interface right is to get people using the task, and, well, the best way to
do that is to include it in an Ant release.

It might be interesting to use this as an experiment to see how an
ant-commons project might work.  That is, the <cc> task wouldn't live in the
Ant 1.x tree, but in its own 'C/C++ tasks' project somewhere.  The C/C++
tasks would have an independent release cycle to Ant.  An Ant distribution
would include the latest released cpptasks.jar, which the user could replace
with newer (or older) versions if so desired (just like the packages in your
favourite linux distro).

* Replace the files for type and task defs, with an XML
descriptor.  The motivation for this change is to move us incrementally
towards an antlib solution.  This first step would let us try out a format
internally for our built-in, optional, and experimental tasks.  It would not
be a published format, and would only be used in our own Jar files.  The
<typedef> and <taskdef> tasks would not support the XML format (though an
experimental <x-import> task might).

The XML format would start off very, very simple, without much more info
than currently in the files.  Probably just a name ->
classname mapping, and some versioning info.  It might be XDoclet generated,
or might be hand-crafted.

The main difference between the new and old descriptors will be 1) XML
format rather than .properties file, which makes it very easy for us to add
new meta-info (like 'deprecated' or 'experimental' flags, say), and 2) every
Jar in $ANT_HOME/lib would be able to include a descriptor, rather than
there being a single descriptor.

If we can squeeze this into the 1.5 release, then we will be able to start
releasing groups of tasks independently of the engine, and have a good
starting point for adding an <import> task.

What are people's thoughts on this?  If no-one is going to -1 this proposal,
I can go over the various antlib proposals that are sitting around, and come
back with a more solid plan.


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

View raw message