Xavier Hanin wrote:
On 5/7/07, Steve Loughran <[EMAIL PROTECTED]> 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)
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
