ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: auto download of antlibs
Date Tue, 08 May 2007 13:27:56 GMT
On 5/8/07, Steve Loughran <stevel@apache.org> wrote:
> Xavier Hanin wrote:
> > On 5/7/07, Steve Loughran <stevel@apache.org> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message