Xavier Hanin wrote:
On 5/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 - http://ant.apache.org/projects.html
>but have a separate url for each antlib.
>? somthing like: http://ant.apache.org/antlibdefintions/<package>.xml
>for example:
>http://ant.apache.org/antlibdefintions/net.sf.antcontrib.xml
>
>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 ant.antlib.org.example.something.version 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">
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
