On 5/4/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Fri, 04 May 2007, Steve Loughran <[EMAIL PROTECTED]> wrote:
> 1. add a -offline argument to say "we are offline". this will set a
> property, (and.build.offline) 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,
steve.
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.
Xavier
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
