> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Friday, 4 May 2007 5:56 PM > To: Ant Developers List > Subject: Re: auto download of antlibs > > On 5/4/07, Steve Loughran <[EMAIL PROTECTED]> 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? > > > > > 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). > > > 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? > 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? 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? Cheers, Steve. -------------------------- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
