On Fri, 2 Aug 2002, Bruce Atherton wrote: > Compare that to the cost for Subversion users of leaving it out of Ant > proper. Retrieving code from SCM systems is core to performing builds, > which is why we support such a variety of them. If a Subversion task is not > part of Ant, everyone who wants to use it has to find the task class in > their Subversion installation and include a <taskdef> with the appropriate > classpath. We couldn't easily share build files with Subversion tasks
Beeing able to do <taskdef> with an explicit classpath ( instead of putting all the jars in ant/lib ) is a benefit. And you don't need to use the classname - you can just have a resource with all the task ( META-INF/subversion.tasks ). That would make your task available to existing ant1.5 (and 1.4) users and you'll be able to make changes independent of the long ant release cycle. We also hope that antlib will be available in 1.6 and will automate a lot of this. > As far as the maintenance burden goes, I've been a contributor to the > Subversion project for a year now, so I'm willing to take on all the > maintenance duties there, as well as to provide the task in the first place. The problem is that your task will only be available in the next ant release - which may take a while. We don't even know how it'll be called - it may be 1.6, 1.9 or even 2.0. If you keep it in subversion CVS - all commiters on subversion will be able to work on it. In ant - ant commiters will have to make the changes. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
