Stefan Bodewig wrote, On 22/04/2003 12.40:
On Tue, 22 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
Versioning,
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.
[EMAIL PROTECTED]
;->
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 antlibs.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------