ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: Subversion in Ant (was Re: Attribute naming)
Date Sat, 03 Aug 2002 00:45:35 GMT
At 12:27 PM 8/2/2002 -0700, you wrote:
>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

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 

Besides, I think this is an argument to increase the rate of releases, if 

>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

:-) 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:   <>
For additional commands, e-mail: <>

View raw message