On Mon, 8 Jul 2002 [EMAIL PROTECTED] 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 successfull. > > 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 ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
