On 5/7/07, Steve Loughran <[EMAIL PROTECTED]> wrote:
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.
Indeed, good point.
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.
Good point too.
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" />
And wher is the version information? And how do we map this package
name to an organization/module name couple? What do you think of
providing all information:
<antlib uri="org.example.something"
org="org.example"
module="example"
rev="1.3"
conf="example" />
The trick here would be to make it a no-op if there was already an
antlib defined into the namespace.
Yes, would be a nice trick.
[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">
Is it a resource or a resource collection? I'm not familiar with the
Resource API yet...
Moreover, where do the module information (org/module/rev) come from?
Shouldn't we provide them? As a side note, it's very similar to the
current ivy:cachepath task. The main difference is that ivy:cachepath
is a task, not a resource. But to be a resource I think we'd need some
kind of lifecycle management for resources.
Xavier
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
