ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: auto download of antlibs
Date Mon, 07 May 2007 12:40:32 GMT
Xavier Hanin wrote:
> On 5/4/07, <> wrote:
>> >> > we'd need a metadata tree mapping antlibs to well known packages,
>> >> > but that is not too hard. JSON, perhaps.
>> >>
>> >> Not sure.  Who'd maintain it?
>> >
>> >It should be some xml format.
>> >I think that it should be on the ant site
>> >and ant committers would be the updaters of it.
>> >- this would be similar to the
>> >related projects page -
>> >but have a separate url for each antlib.
>> >? somthing like:<package>.xml
>> >for example:
>> >
>> >
>> >of course this raises the issues of version. One may not want
>> >the lastest
>> >version of a particular antlib.
>> There is a solution for versioning issues ... or doesnt solve a
>> Maven-repo
>> versioning of multiple formats?
> mm, the problem is not to store multiple versions on the repo, but to
> know which one to pick from the antlib URI. As far as I understand
> Steve proposal, the idea would be to introduce automatic download
> based on the current format of antlib declaration, which only contains
> a package, and no version information.

You'd have to include a version. One thing you could do is 
lib:xmlns="antlib://org/example/something#2.13" ...but that would place 
the version into the namespace, which is too early to read in/expand ant 
properties, and you'd have to update the xmlns declaration everywhere 
you used it...that's a no-no in a big project.

there's also the issue of setting up your ivy conf before the build. Now 
unless we want to be maven-style and look for properties in undocumented 
propertlies like and secretly 
extract the version info from there, we need an explicit declaration of 
versions. Also there's the security issue.

I've been thinking more what we could do with tasks rather than fully 
automated download.

As a first pass, you could combine an ivy download with a typedef, 
hooking in to a named ivy conf:

<antlib uri="org.example.something" conf="example" />

The trick here would be to make it a no-op if there was already an 
antlib defined into the namespace.

[speaking of which, is there a way of enumerating all currently 
declaraed antlibs?]

I'm also thinking of an <ivy:ivypath> resource that let's you declare a 
path inline

  <ivy:ivypath conf="example">


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

View raw message