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 ).
It isn't explicit classpath vs. putting jars in ant/lib. It is explicit classpath vs. doing nothing.
I can use <cvs> with no overhead other than making sure the cvs client is in the PATH. Same with almost all other SCM tasks. It would be nice if the same were true of Subversion (and Stellation and arch).
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.
I take your point, but there is no reason that couldn't be done from Ant as well. For example, we could have a page on the Ant site that detailed the list of new tasks that people could access early (before 1.6 release) by using <taskdef>. This would actually be beneficial in getting more testing done on new tasks before release, too. Initially there would be the overhead for users that I am complaining about, but eventually it would disappear.
Besides, I think this is an argument to increase the rate of releases, if anything.
We also hope that antlib will be available in 1.6 and will automate a lot of this.
I don't see how antlib changes what I am saying, although perhaps I am misunderstanding. You still have to point to where a task's JAR file is, don't you? Isn't that what the "file" attribute does? Either that, or find the file and copy it into antlib. Either way, it is some overhead for the user although perhaps it is less than what they have to do now.
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.
Nice try! I'm not wandering into that topic. :-)
Again, this just shows that there will be a time period during which that overhead I am trying to avoid will have to be endured. At least if the task is part of Ant it will eventually be integrated, as opposed to the alternative.
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.
:-) Not CVS. Subversion committers love their dogfood.
Your argument actually favours keeping it in Ant. The Subversion committers are all brilliant, but they are completely devoted to C. Although there are probably a couple that write Java, most seem to be annoyed at how much Java is trying to reinvent the world when there are perfectly workable C solutions available. These are guys who eat, sleep, and breathe autogen, make, and libtool. There is a reason that writing an Ant task has never even been brought up on the svn mailing list.
Besides, the issue of changes to the program is overblown. By using the command line client to provide the interface, there will be little in the way of changes necessary.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
