ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [warning inflammatory email] Stagn-ant?
Date Tue, 09 Jul 2002 00:57:38 GMT wrote on 07/09/2002 12:58:07 AM:

> On Mon, 8 Jul 2002 wrote:
> > For me an acceptable process would be that the committers decide to 
> > 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 
> > soon as possible
> >         - Vote for both, and merge into a new proposal.
> I have another one:
> - vote for neither, and migrate functionality in ant1.x incrementally 
> with a lot of thinking ( instead of 'as soon as possible' ).
> It seems that's what we are doing anyway.
Yep, that's valid, but an unstated direction.

> As for 'maintenance mode' - we kind of are in this mode for many
> parts of ant ( the core ), and that's IMHO the reason ant is 
> successfull.
Stability of the core != success. It certainly helps, but there are lots 
of other factors.

> If you want to develop an xml programming language - nothing can stop 
> but please don't call it ant ( or ant2 ).
I wasn't planning on it....if I wanted to do that, I'd be working on 
making Jelly and Jexl an ant replacement in earnest.

> I hope ant1.6 will get one of the current classloading / optional 
> proposals - if not, then 1.7 will certainly do. 
> I don't see anything technical to prevent doing that ( in a backward
> compat. way ). Spending time on finding the best solution is good.
Sure. All things come to he who waits. But 'finding the best solution' for 
Ant 1.x wasn't what either of the proposals set out to do. If that was the 
goal, it could have been a lot easier to integrate in.

> However tomcat is a complex project - and most things in the build.xml
> are there because something needs them. I doubt ant ( or any other 
> build tool ) could have all the tomcat needs covered ( and if it 
> does, it'll be a very complex tool, since few projects need all that ).
Tomcat is a complex project. But then again there are far more complex 
projects out there too. But there are good bits of Tomcat's and Ant's 
build files that never get seen or moved into a common place, and should 

Other projects have jdk compilation dependencies too, and these should be 
supported somehow in the base ant, rather than in every project.

> Gump running all the existing projects without error is the minimum.
> ( that includes running all existing user-defined tasks in 
> jakarta/xml/etc ).
So that means:
a) no API changes to the project/target/task/datatype
b) must be able to run existing build files.

Seems reasonable to me.

> And no change just for the sake of changing ( like name changes, 
> cosmetics, etc ).
'Name changes' are often very important and assist greatly in 
understanding something. For example, if I were to keep referring to Ant 
as Gump, people would get very confused.

dIon Gillard, Multitask Consulting

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