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:23:18 GMT
On 5/7/07, Stephen McConnell <mcconnell@dpml.net> wrote:
>
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Friday, 4 May 2007 5:56 PM
> > To: Ant Developers List
> > Subject: Re: auto download of antlibs
> >
> > On 5/4/07, Steve Loughran <stevel@apache.org> wrote:
> > >
> > > One thing I've been thinking of this week is how could we work with
> > > Ivy for automatic antlib download.
> > >
> > > No code right now, just some thoughts
> > >
> > >
> > > 1. add a -offline argument to say "we are offline". this will set
> > > a property, (and.build.offline) and the <offline> test will
> > > work. It is meant to tell things like Ivy that we are offline. At
> > > some point we could add some way for Ant to guess whether the net
> > > is there or not, if java integrates with the OS properly (there is
> > > an API call for this in J2ME, just not Java SE)
> >
> > This makes me think that we could improve how Ivy deal with
> > online/offline mode. Indeed for the moment Ivy doesn't really
> > know which repository requires a network access and which
> > doesn't. It would be nice if Ivy would know that, so that
> > even if offline mode you could still use alocal repository
> > (for antlib testing for instance).
>
> Are you describing a policy at the level of:
>
>   a) a multi-project build decision?
>   b) a specific target project build decision?
>   c) a repository access decision?
>   d) some or any of the above?
I'm describing how Ivy could be improved to better deal with a
situation where the user do not have network access. You can already
deal with that pretty efficiently in Ivy, but you have to define
several settings, to avoid using remote access when it's not
available. Having something easier for the user in this common
situation would be interesting.

>
> >
> > >
> > > 2. when we encounter an element (or even an attr) in an
> > > unknown antlib xmlns, and we want to map that to a
> > > projectcomponent, we hand off resolution to an antlib
> > > resolver. We would have one built in (the failing resolver),
> > > would default to the ivy one if it was present, and
> > > provide some way to let people switch to a different one.
> >
> > This sounds like a good idea.
> >
> > >
> > > 3. an antlib resolver would do the mapping from antlib package to
> > > artifacts (problem one),
> > Yes, and note that we have to consider the version too.
>
> If you assume you are keying of a url, then no ..
>
> In such a scenario you can bring thing back to the url protocol handler and
> delegate the problem to the handler.  For example I may want to assert any
> of the following:
>
>   a) a specific version artifact
>   b) the latest version of an artifact
>   c) an artifact with a versioned constraint range
>
> Using Metro/Depot/Transit the following may be equivalent:
>
>   artifact:jar:org/apache/ant/ant#1.7
>   link:jar:org/apache/ant/ant
>
> The first url references an absolute version, the second is like a symlink
> (typically referencing the latest version).
Fine, so you consider the version.

>
> >
> > > then download the metadata for that artifact, pull it down
> > > and all its artifacts
> > >
> > > 4. we would then <typedef> the lib with the classpath that
> > > is set up by the resolver
> >
> > One question here: is it the responsibility of the resolver
> > to keep artifacts in a cache, or put artifacts in an Ant
> > managed cache.
>
> Isn't that an implementation decision?
I don't think so. If Ant provides a pluggable mechanism for automatic
download of antlibs, it will have to define if once the files are
downloaded they are under Ant control, or stay under control of the
plugin.

>
> > This is important to specify how things are
> > going in offline mode. Ivy already has pretty good support
> > for offline mode, and I think we could improve it (see
> > above). But this is important to consider when specifying the
> > role of the antlib resolver.
>
> What do you mean by offline?
By offline I mean with no network access.
>
> Typically this subject is about policy on resource resolution which is not
> simply a question of establishing a remote connection.  Are we making
> assumptions about cache content?  Is the cache a trusted repository?
>
> > >
> > > we'd need a metadata tree mapping antlibs to well known
> > packages, but
> > > that is not too hard. JSON, perhaps.
> > Not too hard, except maybe for version information. I'm not
> > sure that it would be really nice to get the latest version
> > by default, making the build system automatically updated is
> > not necessarily a good idea (at least users have to keep very
> > good control over that).
>
> Yep - basically your describing the policy you want to apply with respect to
> artifact resolution.  If its absolute versioning are you assuming Dewey
> versioning?  If its latest do you mean latest build or latest stable build
> or latest released build?
This is fully configurable in Ivy, so the user can use whatever he wants.

- Xavier
>
> Cheers, Steve.
>
> --------------------------
> Stephen McConnell
> mailto:mcconnell@dpml.net
> http://www.dpml.net
>
>
> ---------------------------------------------------------------------
> 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