ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: [warning inflammatory email] Stagn-ant?
Date Mon, 08 Jul 2002 08:21:33 GMT
Conor MacNeill <conor@cortexebusiness.com.au> wrote on 07/08/2002 03:29:20 
PM:

> dion@multitask.com.au wrote:
> > 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.

Yep and most nails can be put in place with a hammer. Those screws though 
are an interesting thing...

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

Being an Ant committer, from my perspective it's all in your (and the 
other's) hands. What to do with Ant2 has been an unconscious decision of 
evolution since the proposals were put in place and not voted on. Reading 
the requirements, they need a severe revisit.

For me an acceptable process would be that the committers decide to put 
Ant 1.x into maintenance mode and choose what to do with the existing 
proposals:
        - Vote for one as the usurper
        - Vote for neither, and migrate the functionality into Ant 1.x as 
soon as possible
        - Vote for both, and merge into a new proposal.

> > 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 
Yep, I'm thinking what does an Ant 2 user get that an Ant 1 user doesn't.

> 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. 
I agree, they would emerge, if the core were being used on a wider scale.

> 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 

I mean breaking with backward compatibiliity.

> (<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.
Mostly not in the build file :) But simple things like looping and 
conditional processing are very important., the if and unless just don't 
cut it as the build gets bigger.

> > 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.
But postponement really is a decision. As time goes by I've seen things 
planned for Ant 2 move into Ant 1 and the core classloading and 
optional/built-in issues get worse.

> > 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.
Definitely not, but looking at things like Tomcat's build file scares me 
big time. The other thing is the sheer amount of duplication across build 
files without standardisation, e.g. jdk1.2/3/4 compilation exclusion, on 
vs offline etc.


> Could you elaborate?
My point above was that for simple java projects, a user may not need/want 
a build file. Take for example the typical uni assignment: javac, jar, 
javadoc etc all work off java source code. Being able to:

ant jar javadocs -Ddir=C:\source 

and have it compile source, javadoc source and build a project.jar would 
be nice for ease of adoption. Writing a build file for a simple project 
means less visibility. How about generating a build file for the simple 
case? etc.....

> 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.
Embrace the change :) Ok, I'll bite... What is the acceptable level of 
backward compatibility? Build file? API?

> > 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.
100% agreed. For example, I'd like to remove the idea of properties being 
a task, and untie them and the expression language Ant uses, similar to 
then JSPTL idea.

> > For example, for a 'build' tool, having your top level 
> > element as 'project' is an unusual choice. 
> 
> A rose by any other name ...
Yep, but the 'Project' model in the Ant 2 requirements and proposals is 
really a build model. Gump has more of the 'project' model to it.

> > 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?
Gaining ground had a '?' because it was something that could happen as the 
JSPTL becomes more common place.

> > 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?
Ok, sarcasm off :) Tasks == process == code. Datatypes == data. Right? So 
a taskdef is supposedly the only way of telling ant about code to be 
executed. It's a tad restrictive. Lots of code exists outside of Ant, and 
it'd be good to be able to easily access that from within Ant instead of 
having to create special Ant 'tasks'. 

Datatypes are also similar, and represent generic java objects. Being able 
to have them defined, but not be able to do anything with them except add 
them to tasks is frustrating. How about accessing their properties, for 
example.

> > 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.
So, where to from here? Do the other committers feel like Ant 2's time is 
nigh?

--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message