[Fwd: Some Thoughts on Ant 1.3 and 2.0]

[Steve Loughran <st...@apache.org>]

This is just something I have in my archive from long ago, discussion on 
what was needed for Ant 1.3 and up.

I note that some of them, like XML docs, are still on the todo list :(

-------- Original Message --------
Subject: Some Thoughts on Ant 1.3 and 2.0
Date: 27 Oct 2000 14:29:07 +0200
From: Stefan Bodewig <bo...@bost.de>
Reply-To: ant-dev@jakarta.apache.org
To: ant-dev@jakarta.apache.org

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
afraid).

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
executable.

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
users.

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".

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [Fwd: Some Thoughts on Ant 1.3 and 2.0]

[Alexey Solofnenko <tr...@gmail.com>]

I would also add parallel executor.

- Alexey.
-- 
Alexey N. Solofnenko trelony at gmail.com <http://gmail.com>
home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 hours usually)

Re: [Fwd: Some Thoughts on Ant 1.3 and 2.0]

[Steve Loughran <st...@apache.org>]

Stefan Bodewig wrote:
> On Mon, 23 May 2005, Steve Loughran <st...@apache.org> wrote:
> 
> 
>>This is just something I have in my archive from long ago,
>>discussion on what was needed for Ant 1.3 and up.
> 
> 
> Someday I'll go and dig out a five year old mail to hold against you
> ;-)

pick one where I dont understand properties, or why you cant have two 
attributes with the same name. Come to think of it, I still dont 
understand why the latter is the case...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [Fwd: Some Thoughts on Ant 1.3 and 2.0]

[Stefan Bodewig <bo...@apache.org>]

On Mon, 23 May 2005, Steve Loughran <st...@apache.org> wrote:

> This is just something I have in my archive from long ago,
> discussion on what was needed for Ant 1.3 and up.

Someday I'll go and dig out a five year old mail to hold against you
;-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org