ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Ant1.9 Refactoring?
Date Wed, 28 Nov 2001 10:33:02 GMT

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 these 
leaps may turn out to be bad choices down the road and we will end having to 
support it none the less.

There is clearly a need to do something to experiement but it is clearly not 
something we can do within the main trunk. Perhaps there is another 
alternative. Certainly there is quite a few things that we need to experiment 
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 contents 
contain the word "class"? were they last modified after time X?
* creation of infrastructure to support *coloring* and other 
"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 independent 
of what they are (ie files, inside a zip, on ftp server etc).
There is a huge amount of work to be done in this area.

In the context of Ant2 we have talked about rearranging ant to have 3 largely 
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 the 
tasks look like. It defines the notion of fileset and so forth.

We have talked about breaking (3) down into groups of tasks somehow. I am 
infavour of breaking them down on groupings like
* jdk tasks: javac, javadoc, rmic etc
* text tasks: regex replace, fixcrlf etc
* unix tasks: chmod, etc
* file tasks: copy, move, etc
yada yada

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 out 
loud and experimentation to see how things work out.

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, we 
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 create 
a new package ("o.a.t.a.experimental.*" ?) and possibly we register our tasks 
using a new name (ie the new javac would become x-javac or whatever).

Implementing something like this would allow the full range of 
experimentation adn shouldn't cause any issues. None of the current Ant2 
proposals make any serious effort to define either (2) or (3) so we need to 
have some sort of go at it.

If you want to have your name up in lights or if you want to become an 
committer and currently aren't then this is a perfect opportunity to get in 
;) There is plenty of work to be done and lots of experimentation to be done.

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 to 
ant1.x if we end up staying with that branch. Either way it produces a better 
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 doing 
it and lets see where it goes? 


BTW it probably fits well with Steves proposal



 I don't suffer from insanity. I enjoy every minute of it.

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

View raw message