ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <>
Subject Re: Some Thoughts on Ant 1.3 and 2.0
Date Tue, 31 Oct 2000 05:49:08 GMT
On 10/27/00 5:29 AM, "Stefan Bodewig" <> wrote:

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

Yep. It is quite amazing.

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

Yep. Ant was really released a bit rough from a "how it was designed"

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

I wouldn't mind planning on seeing 2.0 on the order of first quarter next
year. It's not something that has to happen sooner -- just better.

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

Instead of a branch, I'd like to see it in an ant-2.0 workspace. CVS
branches have proved to be clunky way of managing change of the order

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

Actually, I'd like to implement a mini parser that just knew Ant's
particular syntax and remove the need to depend on external libs. Yeah, I
know that sounds weird coming from the guy who is authoring the JAXP spec,
but... It would simplify bootstrapping and distribution.

Ok -- maybe that's a bit over the top.. But it's a thought.

> (*) 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.

Actually, I'd rather break with the past and just say that if I have a
property defined at a upper level, and it's not reassigned at a lower level,
then you get the upper level -- but if it is reassigned at a lower level --
you get the lower level. It's simple and to the point.

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

Yes. The build file defines the static representation of the build. However,
given a scripting system that has exposure to the tree of the build, it
should all be mutable (including the ability for scripts to remove/add tasks
-- and tasks to be able to go through the tree and affect things).

> (*) 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.

Yep. The tasks can be cleaned up a bit.

> (*) 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).

Order: 1) specified pick up location in the build file
       2) ~/.ant/ext
       3) ANT_HOME/ext

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

In META-INF/anttask.xml

> (*) 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.

+1 -- Ant was always meant to have a tool on top of it.

> (*) 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".

Yep. In fact, I'd really be for making Ant simpler again in the presence of
a antconfig that could take care of things on a platform or other basis.
After all -- it seems that most modifications of properties and such are
wanted to deal with installation or user local items in the same way that
config is used for C based programs.

James Duncan Davidson                              
                                                                  !try; do()

View raw message