RE: auto download of antlibs
> -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > 3. an antlib resolver would do the mapping from antlib package to > > artifacts (problem one), > > actually a pretty big problem. Which may explain why two JSRs are dealing with the subject: http://jcp.org/en/jsr/detail?id=294 http://jcp.org/en/jsr/detail?id=277 Cheers, Steve. -- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: auto download of antlibs
> -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 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 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]
RE: auto download of antlibs
> -Original Message- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: Friday, 4 May 2007 5:27 PM > To: Ant Developers List > Subject: auto download of antlibs > > > 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 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) Sounds like we are mixing a characteristic of a network connection with a policy decision. When we talk about being offline - we are normally describing a situation under which a TCP/IP connection is unavailable. When developers discuss '-offline' as a policy what this often translates to is that they want to assert a rule preventing the automatic downloading of artifacts. Recognizing this difference enables recognition of a bunch of other possibilities: a) I have a artifacts that I depend upon I want to modify the logic used in the resolution of said artifacts - do I want to resolve artifacts over a remote network connection? - are internet resolvable connections ok? - am I really talking about shades of gray relative to a collection of repositories - in effect, am I designing a artifact retrieval policy - am I talking about trust? - am I talking about artifact integrity? b) What is the state of my cache? - was the cached artifact established with the same policy as the policy I'm currently asserting - does my cache management system associate existence policy with the artifact - it the cached object verifiable - does my build policy imply anything on my caching policy - is my cache sharable and if it is, what am I asserting in terms of policy c) What is the relationship between build process, cache, and shared repositories? - am I trusted? - how can clients validate me, my cache, my policy, my artifacts - does my build process trust my cache (given that interim dependent builds may be using policies that are not under my control - e.g. Eric uses Antlib X which has dependencies on jar X, Y, and Z > 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. You can do this without mentioning Ivy so long as you have the mechanisms to include URL protocol handlers. Example of a working build.xml file: The above build works if I put around about 5 specialized jar files into my ./ant/lib directory and invoke: $ ant Or more typically, the mechanism I use on more than one hundred Ant based projects (without anything in .ant/lib): $ build In both cases what I am doing is making Ant URL aware - as such "local:template:dpml/tools/standard" is recognized as a protocol handler and the handler recognizes content types and maps into place the appropriate content handler which in this case simply drags in template build file. The template file contains the following statements: ... The task establishes an project helper that deals with uris for things like antlib plugins (and a bunch of other protocol handlers that let me deal with cached resources, resources on remote hosts, local preferences, services based on independent virtual machines, deployment scenarios for local or remote applications, basically most of the things you need in a fully functional build environment. In effect - it basically does the setup of the machinery needed to override Ant behaviour when resolving tasks and data types using the URL machinery bundled in the JVM. > 3. an antlib resolver would do the mapping from antlib > package to artifacts (problem one), then download the > metadata for that artifact, pull it down and all its artifacts Sounds like a protocol handler that captures sufficient information to represent a classloader chain together with som information about the deployment target. One example that approaches this is the DPML part definition which encapsulates (a) generic info, (b) a deployment strategy, and (c) a classloader chain definition. http://www.dpml.net/metro/parts/index.html In the DPML model the deployment strategy is dynamic and in out environment we have several strategies we use on a regular basis. One of these is a antlib strategy which simply identifies the path to the antlib resource and the namesp
Re: auto download of antlibs
On 5/7/07, Steve Loughran <[EMAIL PROTECTED]> wrote: Xavier Hanin wrote: > On 5/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> > 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? >> > >> >It should be some xml format. >> >I think that it should be on the ant site >> >and ant committers would be the updaters of it. >> >- this would be similar to the >> >related projects page - http://ant.apache.org/projects.html >> >but have a separate url for each antlib. >> >? somthing like: http://ant.apache.org/antlibdefintions/.xml >> >for example: >> >http://ant.apache.org/antlibdefintions/net.sf.antcontrib.xml >> > >> >of course this raises the issues of version. One may not want >> >the lastest >> >version of a particular antlib. >> >> >> There is a solution for versioning issues ... or doesnt solve a >> Maven-repo >> versioning of multiple formats? > mm, the problem is not to store multiple versions on the repo, but to > know which one to pick from the antlib URI. As far as I understand > Steve proposal, the idea would be to introduce automatic download > based on the current format of antlib declaration, which only contains > a package, and no version information. > You'd have to include a version. One thing you could do is lib:xmlns="antlib://org/example/something#2.13" ...but that would place the version into the namespace, which is too early to read in/expand ant properties, and you'd have to update the xmlns declaration everywhere you used it...that's a no-no in a big project. Indeed, good point. there's also the issue of setting up your ivy conf before the build. Now unless we want to be maven-style and look for properties in undocumented propertlies like ant.antlib.org.example.something.version and secretly extract the version info from there, we need an explicit declaration of versions. Also there's the security issue. Good point too. I've been thinking more what we could do with tasks rather than fully automated download. As a first pass, you could combine an ivy download with a typedef, hooking in to a named ivy conf: And wher is the version information? And how do we map this package name to an organization/module name couple? What do you think of providing all information: The trick here would be to make it a no-op if there was already an antlib defined into the namespace. Yes, would be a nice trick. [speaking of which, is there a way of enumerating all currently declaraed antlibs?] I'm also thinking of an resource that let's you declare a path inline Is it a resource or a resource collection? I'm not familiar with the Resource API yet... Moreover, where do the module information (org/module/rev) come from? Shouldn't we provide them? As a side note, it's very similar to the current ivy:cachepath task. The main difference is that ivy:cachepath is a task, not a resource. But to be a resource I think we'd need some kind of lifecycle management for resources. Xavier -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto download of antlibs
Xavier Hanin wrote: On 5/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> > 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? > >It should be some xml format. >I think that it should be on the ant site >and ant committers would be the updaters of it. >- this would be similar to the >related projects page - http://ant.apache.org/projects.html >but have a separate url for each antlib. >? somthing like: http://ant.apache.org/antlibdefintions/.xml >for example: >http://ant.apache.org/antlibdefintions/net.sf.antcontrib.xml > >of course this raises the issues of version. One may not want >the lastest >version of a particular antlib. There is a solution for versioning issues ... or doesnt solve a Maven-repo versioning of multiple formats? mm, the problem is not to store multiple versions on the repo, but to know which one to pick from the antlib URI. As far as I understand Steve proposal, the idea would be to introduce automatic download based on the current format of antlib declaration, which only contains a package, and no version information. You'd have to include a version. One thing you could do is lib:xmlns="antlib://org/example/something#2.13" ...but that would place the version into the namespace, which is too early to read in/expand ant properties, and you'd have to update the xmlns declaration everywhere you used it...that's a no-no in a big project. there's also the issue of setting up your ivy conf before the build. Now unless we want to be maven-style and look for properties in undocumented propertlies like ant.antlib.org.example.something.version and secretly extract the version info from there, we need an explicit declaration of versions. Also there's the security issue. I've been thinking more what we could do with tasks rather than fully automated download. As a first pass, you could combine an ivy download with a typedef, hooking in to a named ivy conf: The trick here would be to make it a no-op if there was already an antlib defined into the namespace. [speaking of which, is there a way of enumerating all currently declaraed antlibs?] I'm also thinking of an resource that let's you declare a path inline -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r535764 - /ant/core/trunk/xdocs/projects.xml
no worries ;) On 5/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: ups - thanks. Just applied the patch with whitespace check - not language check ;) Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: svn commit: r535764 - /ant/core/trunk/xdocs/projects.xml
ups - thanks. Just applied the patch with whitespace check - not language check ;) Jan >-Ursprüngliche Nachricht- >Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Gesendet: Montag, 7. Mai 2007 09:01 >An: [EMAIL PROTECTED] >Betreff: svn commit: r535764 - /ant/core/trunk/xdocs/projects.xml > >Author: kevj >Date: Mon May 7 00:01:12 2007 >New Revision: 535764 > >URL: http://svn.apache.org/viewvc?view=rev&rev=535764 >Log: >-typo > >Modified: >ant/core/trunk/xdocs/projects.xml > >Modified: ant/core/trunk/xdocs/projects.xml >URL: >http://svn.apache.org/viewvc/ant/core/trunk/xdocs/projects.xml? >view=diff&rev=535764&r1=535763&r2=535764 >=== >=== >--- ant/core/trunk/xdocs/projects.xml (original) >+++ ant/core/trunk/xdocs/projects.xml Mon May 7 00:01:12 2007 >@@ -233,7 +233,7 @@ > > > >-Ant Shell Extension is a Windows Explorer >enhacement that adds a contextual >+Ant Shell Extension is a Windows Explorer >enhancement that adds a contextual > menu when you right click over an Ant xml file, so >you can execute all the actions > defined in that file without going to a command >console or starting your favourite > IDE to make a simple clean. > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r535764 - /ant/core/trunk/xdocs/projects.xml
Author: kevj Date: Mon May 7 00:01:12 2007 New Revision: 535764 URL: http://svn.apache.org/viewvc?view=rev&rev=535764 Log: -typo Modified: ant/core/trunk/xdocs/projects.xml Modified: ant/core/trunk/xdocs/projects.xml URL: http://svn.apache.org/viewvc/ant/core/trunk/xdocs/projects.xml?view=diff&rev=535764&r1=535763&r2=535764 == --- ant/core/trunk/xdocs/projects.xml (original) +++ ant/core/trunk/xdocs/projects.xml Mon May 7 00:01:12 2007 @@ -233,7 +233,7 @@ -Ant Shell Extension is a Windows Explorer enhacement that adds a contextual +Ant Shell Extension is a Windows Explorer enhancement that adds a contextual menu when you right click over an Ant xml file, so you can execute all the actions defined in that file without going to a command console or starting your favourite IDE to make a simple clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
