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 Wed, 07 Aug 2002 20:36:11 GMT
At 08:34 AM 8/7/2002 +0200, Stefan Bodewig wrote:

>This is why we need <antlib> so badly.  It must become as easy as
>dropping a file in a given location to install a task.

Right. Even better would be if different projects could locate an ant 
installation and automatically install their tasks. That would largely 
negate my concerns. Perhaps a project could do this as part of their 
install process:

     ant -install newtask.jar

which would copy the project's jar file into the $ANT_HOME/lib directory. 
That method could also be used by package maintainers.

If I'm covering well-trod ground here, forgive me. I admit to having 
glossed over some of the antlib discussions.

>Or you could go about it the other way around (like Maven or Centipede
>do) and download all the stuff at build time (I think Centipede
>bundles the ant-contrib tasks, dunno for sure).

Yes, but then the burden is on me to write a more complex build script that 
can detect when it needs to bootstrap itself. There is still a chilling effect.

>We seem to agree here 8-)

I think we have a meeting of minds about most of these issues, we just 
disagree on the relative importance of two goals we both regard as important.

>and here as well.  I've added Subversion support to Gump.

Fantastic! I talked to Sam about doing this a while ago and did a bit of 
work on it, but I didn't (and don't) really understand how to integrate C 
language builds into Gump. I can see how to use <script> to do the makes, 
but I got lost trying to figure out how to describe and use C libraries as 

Are you defining separate Gump builds for APR and APR-UTIL and making those 
dependencies? What about HTTPD-2 and Neon?

I assume this is on your private Gump instance since I don't see it in the 
nightly. Are you planning on sending the nags to svn-breakage? I haven't 
seen any there yet.

>It certainly doesn't have to be Subversion.  But it would be helpful
>if it was a task that is in widespread use.

Ok, so if I can come up with a task that would get widespread use and can 
be used as a model for people to use, one that didn't have these legacy 
issues to overcome, you'd be ok with a Subversion task in Ant?

Let me think on that one. I'll try to come up with a few suggestions.

>If you follow the logic of "many people will use it, so bundle it",
>people will still want to include their tasks in Ant's distribution -
>and if it just was for the same strategic reasons you are following.

If many people would use a task, then that is indeed an argument for 
bundling it. If, say, 30% of Ant users are manually adding a particular 
task to Ant to make it work the way they want to, then we are making the 
use of Ant harder than it needs to be.

Of course, we don't know how many people will be using Subversion yet, that 
was just wishful thinking. That's why I bring up other points like a SCM 
task being core to a build system.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message