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 Tue, 08 May 2007 10:40:32 GMT
Xavier Hanin wrote:
> On 5/7/07, Steve Loughran <> wrote:

>> 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" />

I'd expect all version info to be in ivy.xml; when I declare a 
configuration in the <antlib> declaration, I say which ivy configuration 
I want, without any version info embedded in the build files

>> 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.

that's what we would have to add above what is there today.

>> 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.

class Resource extends ResourceCollection :)

I do think a resource version of cachepath is exactly what we want. We 
dont need a lifecycle for resources either, provided the resource can 
track whether it has resolved (or failed to resolve) yet. it just does a 
resolution the first time its needed (this is how filepaths work)


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

View raw message