ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [warning inflammatory email] Stagn-ant?
Date Mon, 08 Jul 2002 14:58:07 GMT
On Mon, 8 Jul 2002 wrote:

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

I have another one:

- vote for neither, and migrate functionality in ant1.x incrementally and
with a lot of thinking ( instead of 'as soon as possible' ).

It seems that's what we are doing anyway.

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 

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

If you want to develop an xml programming language - nothing can stop you, 
but please don't call it ant ( or ant2 ).

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

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.

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

I agree with that :-)

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

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

Gump running all the existing projects without error is the minimum.
( that includes running all existing user-defined tasks in 
jakarta/xml/etc ).

And no change just for the sake of changing ( like name changes, 
cosmetics, etc ).


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

View raw message