ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Ant1.9 Refactoring?
Date Thu, 29 Nov 2001 20:43:35 GMT

----- Original Message -----
From: "Peter Donald" <>
To: <>
Sent: Wednesday, November 28, 2001 2:33 AM
Subject: Ant1.9 Refactoring?

> Hi,
> There has been a lot of talk about refactoring and cleaning up ant1.x
> recently. Mostly it has been about how different tasks work and should
> operate and so forth.
> Unfortunately in the ant1.x we can not make any large "innovative" leaps
> because we have the compatability monkey sitting on our shoulder. Also
> leaps may turn out to be bad choices down the road and we will end having
> support it none the less.

We are constrained by success and the fact that what we have right now is
not the most coherent design possible -which is often a feature of evolved

However, although we are mostly stuck with the existing build.xml syntax, we
do have flexibility in how that is implemented, which is where refactoring
comes in to play.

I am +1 for refactoring, but think that some of it could be done in a way
which feeds back into the main branch early on.

For example, say we decide on a lifecycle model for tasks and an interface
to be supported by tasks and their containers: Taskable and TaskContext

1 .we could then go "class Task extends Taskable" without breaking any task
which didnt overload the methods in the interface.

2. then the task loader code could move from checking for "extends Task or
has void execute()" to "implements Taskable or has void execute()", and
suddenly we have removed the requirement for tasks to be derived from Task,
and provided a compile time alternative to the reflection solution.

3. Same for the task container. we can factor out functionality, specify it
in an interface and implement it in AntBaseTaskContainer, especially if we
work with people who provide containers (netbeans, eclipse, antidote &c) to
see what they need.

Once things like that are in there, we can slowly migrate tasks to the new
interfaces, keeping tasks off the main branch while they were being upgraded
and then pulling them in.

The same goes for stuff like Jose Alberto's descriptor code. It is
beneficial. it wont break existing stuff, we just need to work on it till
everyone is happy with the model and then put in in the main system. Perhaps
the feasilibity of such tactics depends on the size of the undertaking: it
is easier to play with new tasks than it is to rework in an
experimental manner and not break existing code.

> There is clearly a need to do something to experiement but it is clearly
> something we can do within the main trunk. Perhaps there is another
> alternative. Certainly there is quite a few things that we need to
> with, some of the more salient ones being
> * making the names of the attributes/elements consistent


> * creation of cullers/selectors. ie they select items out of a fileset
> accoring to specific attributes - like are they readable? do their
> contain the word "class"? were they last modified after time X?
> * creation of infrastructure to support *coloring* and other

+1. Does conor's datatype patch make this possible today?

> "environment" based dependency stuff
> * creation of generic infrastructure to support "structural" based
> dependency stuff
> * refactoring some of the classes into beans so that no task directly
> references another task
> * abstract notion of item sets from dependset, fileset and so forth
> * creating a VFS/URL layer that tasks can use to access resources
> of what they are (ie files, inside a zip, on ftp server etc).
> ...

my interests:
dynamic loading of task libraries from a descriptor
use of xdoclet and marked up tasks to generate deployment descriptors, docs

> In the context of Ant2 we have talked about rearranging ant to have 3
> separate sections;
> (1) the container (think the servlet engine + servlet API)
> (2) the framework (think turbine or struts or another web framework)
> (3) the tasks
> (2) is probably one of the most important bits in that it determines what
> tasks look like. It defines the notion of fileset and so forth.

One of the most similar 'frameworks' is the whole taglib model itself. What
is good and bad about that that we can apply (or omit) from the anttag

> Now by refactoring using the ant1.x line we could experiment with things a
> lot easier and test/validate our ideas. If there is an idea that holds
> particular merit and can be done in ant1.x's main trunk we will see it
> backported however most of the stuff could be considerer largely thinking
> loud and experimentation to see how things work out.

+1, with the caveat that I think some things should go into the main trunk
early as they are so beneficial to users and task developers, other things
should stay off it until everyone is happy.

This would also let us explore a more compartmentalised method of delivering
components. Instead of a big ant.jar  and optional.jar the refactored
components can be developed and delivered in modules.

> I think it would be advantageous to create an area in which we could
> experiment with these sorts of things. Almost anything could be allowed,
> could throw out all of ant1.xs implementation of X and replace it with
> something kooler. To make sure it doesn't cause any conflicts we could
> a new package ("o.a.t.a.experimental.*" ?) and possibly we register our
> using a new name (ie the new javac would become x-javac or whatever).

+1 for the sandbox.

> Once we reach some sort of stable point we can quickly port them across to
> Ant2 container (if we manage to decide upon one) or backport the changes
> ant1.x if we end up staying with that branch. Either way it produces a
> ant and gives more people the opportunity to participate without having to
> know a masiive amount of history about tasks or worry about backwards
> compatability or anything like that.
> So you want to do something - take "ownership" of a section and start
> it and lets see where it goes?
> Thoughts?
> BTW it probably fits well with Steves proposal

I wasnt thinking quite as radically :-)

Branches can take a life of their own if we arent careful, and this is going
to complicate the world. It will effectively mean a stabilising of the main
trunk while people focus their effort off to the side. Which is not
necessarily a bad thing.

One nice thing about the branch strategy is that we can do stuff that would
break Gump, but dont need to fix the issues immediately. We do need
something like it for testing though. CruiseControl?

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

View raw message