ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hall, John" <>
Subject RE: Some Thoughts on Ant 1.3 and 2.0
Date Fri, 27 Oct 2000 20:32:48 GMT

This may be a post 2.0 consideration, but there are a large number of tasks
in Ant that can be used as part of an software installation project.  I
already use it for just this purpose.  Of course this would probably entail
branching off Ant so that the common components/tasks would be part of both
development efforts.  This way Ant would not be bastardized with
installation tasks and vice versa.  What do you think?


-----Original Message-----
From: Stefan Bodewig []
Sent: Friday, October 27, 2000 6:29 AM
Subject: Some Thoughts on Ant 1.3 and 2.0

Hi, back to Cologne again. 

In London I've talked about Ant to a couple of people and would like
to share my thoughts with you. This is more or less a brain storming
at the moment ... (nonetheless quite long and still incomplete I'm

First of all, the number of people actually using Ant in their
projects has outgrown all expectations - this is great and should also
make us feel a little responsible for their projects.

Ant is in the middle of a consolidation phase towards what will be Ant
2.0 (see below for my vision of what Ant 2.0 should be). To get there
we needed to break some build files during the transition from 1.1 to
1.2 and we will probably need to break some others again with Ant 2.0.

My aim is that we are going to break them no more than _once_
more. I.e. we should try to get a clear vision of what we want to
achieve with Ant 2.0, *document* it and then stick to it, at least for
the near future.

I'm going to give it a start by modifying spec/core.html to reflect
what has been actually implemented in Ant 1.2 and rearrange some
things. Should happen sometime early/mid of next week.

I think the process to get there might take some time. On the other
hand there will be a couple of changes, bug fixes and new features
that won't affect old build environments. I feel we should be prepared
to have a Ant 1.3 release (or 1.2.1 or similar) and maybe even
releases following that (though I hope not) to address this -
personally I'd prefer to get to a shorter release cycle than we had.

This means we'd need to defer all things that could break older
environments to a final step from Ant 1.x to 2.0, using a branch for
that if necessary.

What I'd like to see for 1.3

(*) Vincent's submissions in the data type area.

Collecting command line arguments that occur over and over again for
example. Vincent, what do you think about <argset> and <arg> as
separate entities instead of overloading <arg> to be a container and a
single argument at the same time?

(*) Probably a couple of new tasks. 

I've been thinking about exec-all and transform to accompany execon
and corresponding javaon, javaall and jtransform tasks.

The execon task should get smarter (i.e. the argument generated from
the fileset doesn't have to be the last one) and transform would push
the idea a little bit further. This task would generate the name of a
target file from the name of a source file (like *.c -> *.o), check
whether the target file exists and only execute if it doesn't or the
source is newer and provide both the source- and target name to the

I'd like to refactor all those tasks that have a scanDir method that
filters the files to process (by the <uptodate> logic) at the same
time. Proposal on how I think we could do this will follow.

These tasks should help to satisfy most use cases that ask for loops.

(*) some additional features - like adding out-attributes to a couple
of tasks and so on.

(*) expanding ${} (almost) everywhere

This should include all attributes of <project> and <target> - except
id? - and the #PCDATA sections handled by addText. I'm not sure
whether the latter would interfere with <script> though.

(*) bug fixes of course.

What I'd like to see for 2.0

(*) Switch to JAXP 1.1 and SAX2.

Could happen in 1.3 as well if JAXP 1.1 should be ready by then.

(*) Change of the documentation system to an XML based one.

No matter which DTD or Schema we want to use, it should be something
that can be used to generate HTML as well as printable (PDF)
information. At the same time I'd like to put more documentation
burden on the task writer (i.e. don't accept new tasks unless they are
documented in the "correct" format).

(*) Change of the property system one last time

No matter what we do, there are still some things that need to be
resolved and finalized. Mainly

(1) Master projects overwriting properties in sub projects. Sometimes
you want this to happen, in other cases you do so by accident. The
easiest solution that doesn't change the behavior of current build
files would be something like

<property name="foo" value="bar" scope="file" />

for properties that should not overwrite properties of the same name
in sub builds. If you want to overwrite, use scope="global" which would
need to be the default unless we want to break something existing.

Alternatively add something like <localproperty> for what scope="file"
would do.

(2) Do we want mutable properties or not? Regardless of what we come
up with, we should document it and stick to it.

(*) Make <antstructure> support Schema.

At the same time maybe make tasks give some more help to antstructure
to identify required arguments, default values and so on.

Schema is a lot more expressive than a DTD. This could happen in 1.3
of course, it's a matter of time.

(*) Use a consistent naming for attributes

Instead of using srcdir, dir and basedir for the same thing, we should
agree on one and use it throughout Ant.

(*) Extension tasks

Make extending Ant as simple as possible, i.e. drop a jar file in a
specific directory (ANT_HOME/ext globally or ~/.ant/ext on a user by
user basis).

This jar file must include <taskdef>s to define the tasks, Schema
files to describe the tasks and documentation in the XML format we
agreed on.

The Schema file is there to support GUI tools for example. They could
prompt for required attributes, let you select enumerated attributes
from a list, require integer attributes to really contain numbers ...

I don't view Ant using it itself at the moment.

<taskdef> will probably need some extension so that the author can
specify required libraries and other things.

Things I'd like to see beyond/parallel to that

(*) A GUI tool.

Hope Anthill will really get on the way. Frederic, if you should need
help (like a CVS space to live in), please let us know.

(*) Some kind of front end to satisfy the more complex needs of some

This is where I'd see support for enhanced conditionals and other
things. To quote Duncan: a tool that would be "to Ant what configure
is to make".


View raw message