costin says >I hope everyone realize how many users ant has - I suspect more people >use ant than JDK1.4 today. There are huge investments in time and >learning, books, etc. If we really want a new API for future - it better >be _very_ good.
yeah, ant-dev has #3 traffic count on the nagoya archive; it is institutionalised that it will be hard to move people from ant1 to ant2. to Java1.2+ ----------- Regarding a move to Ant1.2, je m'en fous about running on MSJVM or J#, and indeed J# actually adds collections, and maybe even File.setLastModified(), so maybe Don box will be able to run ant on the CLR after all (*), though of course we will respond to all support calls related to the CLR to nous nous'en fous (DD, Stephane correct?). -The fact that there are bugs related to <java> on MSJVM that we have never fixed because nobody ever reported them, shows that that is not a popular platform. -because you cant go File.setLastModified() a lot of stuff in ant doesnt work so well on 1.1; you can't propagate timestamps. Nobody files bugreps. -FreeBSD was always the showstopper, but they have a later version, right. -Costins comment about avoiding 2.0-isms in the interfaces means we could let someone do 1.1 maintenance, even if we dont even bother to test it ourselves. but we can still use collections in the interfaces. -At the same time, we can fix classloaders in 2.0, and do security managers perhaps too. -I'm against bleeding edge assertions and generics (as is Jon Skeet). Though I think we should add genenerics support in the compiler. We had always said that Ant 2.0 would be Java1.2, even 12+ months ago when it was specced. Maybe it is time to move the Ant to Java1.2, even if that means we have to call it version 2. We still need to be able to build *for* 1.1 (and should test for that), even though we dont build *on* 1.1. Ant2.0 ------- I think its a shame that Conor deleted mutant off CVS, but it has provoked this discussion. Ant 2.0 was meant to be two things 1. a ground up rewrite of the underlying core, written for the problems and needs we are now aware of (containement hosting of ant, support of many tasks from different libraries, classpaths, handling of big build files through demand parsing of the XML elements...) 2. A slighltly modified build file, fixing many of the historical quirks of ant1.x (inclusion of ant libs in some tasks, not others; unknown properties throw exceptions, etc. (OPTION EXPLICIT in VB :) One constraint we have is that the success of ant1.x makes it hard to make incompatible changes, and it also will make it hard to move people off 1.x. If the move to 2.0 takes effort, people will stay with 1.x. Either we make 2.x utterly compelling and easy to move to, or we retain total backwards compatibility. So, here is a Question. How hard is it to redo the core properly, while still supporting the ant1.x build files, and even tasks, and not add any new behaviour other than improvements in classpaths, libraries, demand parsing and the other big features? (*) http://www.gotdotnet.com/team/dbox/spoutlet.aspx#nn2002-07-04 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
