Long Email Warning....
I've spent some time this weekend reading up on the various proposals for Ant 2, and my first reaction is:
'Is Ant dead?'
No :-)
Ant1 continues quite strongly, I think, despite its limitations. I would say many (most?) build operations can be done with Ant the way it is.
Ant 1.x has been around a very long time now, and some of the proposals have been around for more than a year. It seems that there is a general unwillingness to make a move forward.
Unwillingness? Maybe. IMHO, I think the problem comes more from a lack of defined process for adopting a codebase. Is it by majority vote - is there a possibility for veto? If Ant2 is to progress I think the process should be defined but I am unsure as to how to agree the process :-( A timetable and acceptance criteria would be desirable.
Proposals still seem to be heavily rooted in Ant 1.x terminology and technology and offer some 'goodies' to the end user, but little as a driving factor to move to something else is evident.
Are you talking about the end-user visible features? This is probably true. I know Mutant tries to clean up the core so things can be packaged, installed, managed more easily without necessarily providing a huge range of new end-user features in the build files itself. My feeling was that those features would emerge once the core was cleaner. Anyway, I think we need to avoid
http://www.tuxedo.org/~esr/jargon/jargon.html#second-system%20effect
when providing "motivation for moving to something else".
In the meantime, other projects have come along building on top of and next to Ant (Jelly, Maven, Centipede etc), usurping what would seem to be Ant 2's territory. These projects have no 'history' to deal with and can freely move forward with new ideas and technologies, that the Ant team seems reluctant to touch, e.g. scripting, backward compatibility etc.
What do you mean "backward compatibility"? Ant1 is mired in backward compatability! As for scripting, I presume you mean script-like tasks (<if>, <while>, etc) and not the <script> task itself. Is an XML based scripting language the way to go? I really don't know. It would certainly be convenient in cases. Things like <try>-<catch> should be there IMHO. The gradual addition of failonerror attributes to each task is just the wrong way to do it. OTOH, If you need that much logic, why not just go into Java or <script>? We have seen how <antcall> gets abused :-) It is a matter of where it is best to put complex build logic, I guess. I don't know the right answer.
The current unspoken decision seems to be that none of the proposals are acceptable, and that the evolution of Ant 1 is the direction that will be taken, albeit at a slower pace than seems possible elsewhere.
Previous discussions have suggested using Gump as a minimum acceptance criteria. I've certainly tried to have Mutant work effectively with Gump. Again the problem is not having an agreed process. Indefinite postponement seems to be easier than a decision.
Maybe Ant2 will come from outside of ant-dev? Maybe Jelly, for example, will become what everyone uses and people will gradually stop using Ant as their main tool for builds. Maybe it will be a user friendly Forrest/Gump/Centipede combo?
So is it time to revisit what the requirements are for Ant 2 ( http://jakarta.apache.org/ant/ant2/ ) ? What do users actually want? To write xml files and understand the oddities of history? Do people believe that developers want to write build files for small projects?
I sense the suggestion that Ant is suitable for small projects only. Could you elaborate?
With respect to "oddities of history", it is probably also worth asking what is the acceptable level of backward compatability breakage in moving from Ant1 to Ant2. For some people, no break is acceptable even across a major version number increment.
Personally, as a long time user of Ant 1.x, it's interesting reading the existing proposals and seeing how heavily we all have been influenced by some of the key concepts that Ant 1 used. After looking around, maybe we need to throw the bath water out and keep the baby, i.e. go back to the drawing board.
Sure we can go back to the drawing board. Discussions are useful especially "off the wall" ideas. OTOH, I don't think we can have design by committee. It doesn't work very well.
For example, for a 'build' tool, having your top level element as 'project' is an unusual choice.
A rose by any other name ...
The expression language of Ant is also an interesting point, as jexl and jsptl gain ground (?)
I'm not sure where these are gaining ground. Can you give me a few pointers?
Also, the concept of 'tasks' and 'datatypes' - <sarcasm>could we get a little more generic?</sarcasm>
I'm not sure your point here. These are pretty generic concepts so the names seem appropriate. What would you have?
This is not a wholesale swipe @ the current Ant team. I think they do a fantastic job. And I love Ant....
I realise a lot of this has been said already, but it's been a long time since Ant2 has been mentioned seriously, and I personally feel that Ant itself has stagnated, and needs something/someone to poke an iron into the ashes to see if there's any fire left.
I understand your frustration.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
