ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: antlib
Date Tue, 22 Apr 2003 11:40:53 GMT

Stefan Bodewig wrote, On 22/04/2003 12.40:
> On Tue, 22 Apr 2003, Nicola Ken Barozzi <> wrote:
> Has to be part of <antlib> anyway.

And that is why I suggested this. Why reimplement something that is 
already there and has been proposed to be donated to Ant?

>>'auto' download.
> and this is where <uptodate> and <get> kick in.

I don't get it. Do <uptodate> and <get> download to a centralized 
repository? Do they use other mechanisms other than http? Are they 
integrated in antlib? DO they enable the usage of a moniker to get the 
antlib instead of a full URL?

Yes, get and uptodate are a poor man's repository manager.

>>Users would not need to know phisical locations, and have a central
>>antlib repository in the Ant distro, not downloads to ad-hoc places.
> There still are quite different solutions to this.
> The Maven style repositories plus Ruper is one solution.  It would be
> rather easy to build one on top of RPM using the work the jpackage
> people have done.  No adhoc places either - and you get the repository
> database for free.
> I'm not suggesting anything here, I want to point out that there are
> options to solve these issues that are not Ruper.

As always, there are bazillions of solutions to the tasks. Ruper is 
something that is proposed for donation to Ant as a download mechanism.

The repository and metadata are *not* fixed.
They should change as needed by Apache and Ant, so proposals in this 
sense are welcome.


Why is Ant included in many CVS modules? Because it does not have a 
standard and easy way of getting jars.

Why do users have to mess with the ant lib dir to put extensions? 
Because it does not have a standard and easy way of getting jars.

Why is Gump difficult to set up? Also because you have to get installed 
packages. I will use Ruper for that.

>>So I would reuse the same antllib for all projects that need it, not
>>have it downloaded and called ad.hoc for every project.
> But this is a separate step to me.  The first step is to get the basic
> concept clear and implemented.  Users should be able to share the same
> Ant lib by pointing their build files to the correct locations.

That's why I agree that it should be a second step in the definition of 

> I'm the type of user who prefers to perform some extra manual work
> over things happening automagically - and I'd like to keep <antlib>
> available to this type of users 8-)

Definately, never suggested otherwise. The automatism I suggested is 
just an extra feature for antlibs. IMHO it will be heavily used, but 
that's not the point of course.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message