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 10:14:46 GMT
On 5/4/07, Stefan Bodewig <> wrote:
> On Fri, 04 May 2007, Steve Loughran <> wrote:
> > 1. add a -offline argument to say "we are offline". this will set a
> > property, ( and the <offline> test will work.
> Do I sense oata.utils.NetworkUtils?  Might contain some Proxy
> configuration (and if possible detection) code as well.
> > 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.
> OK.
> > 3. an antlib resolver would do the mapping from antlib package to
> > artifacts (problem one),
> actually a pretty big problem.
> > 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
> sounds right.
> > we'd need a metadata tree mapping antlibs to well known packages,
> > but that is not too hard. JSON, perhaps.
> Not sure.  Who'd maintain it?  Maintaining it for our own Antlibs is
> easy, but we wouldn't want the mechanism to only apply for them.  And
> I'd be scared of the security implications of a Wiki driven list or
> something even close to that.
You make a good point. So maybe this would require all information
(module identifier and version) to be in the antlib URL, thus
requiring another antlib url format (maybe with a distinct protocol),
which is not really going in the same direction as you suggested,

Another option from the top of my head: build a module identifier from
the package name, even if it's not very accurate, the only purpose is
to get something unique. It could something like: org = package name;
module = last part of the package name
eg: org.apache.ivy.ant => org = org.apache.ivy.ant; module = ant
This module would not be the antlib module, but only a module with its
only artifact being metadata about the module containing the actual
antlib. This metadata could be in a simple format, JSON, XML or
properties file. Then we can use this metadata to actually download
the antlib. The remaining problem is version information.

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