On 5/8/07, Steve Loughran <[EMAIL PROTECTED]> wrote:
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
And where is the ivy.xml?



>>
>> 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)
This shouldn't be too difficult to handle. The most difficult part for
us is that this is specific to ant 1.7, so we will have a part of our
code base specific to 1.7, and the rest compatible with ant 1.6, so we
will have to be very careful not to introduce ant 1.7 dependency in
the rest of the code base.

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

Reply via email to