ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: auto download of antlibs
Date Fri, 04 May 2007 08:26:25 GMT
On 5/4/07, Steve Loughran <> 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 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).

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

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

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


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

Learn Ivy at ApacheCon:
Manage your dependencies with Ivy!

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

View raw message