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 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) 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. 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 4. we would then typedef the lib with the classpath that is set up by the resolver we'd need a metadata tree mapping antlibs to well known packages, but that is not too hard. JSON, perhaps. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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). 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). Xavier -steve - 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]
Re: auto download of antlibs
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. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto download of antlibs
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]
Re: auto download of antlibs
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? 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/package.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. Peter 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. Stefan - 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]
AW: auto download of antlibs
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/package.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? Or we provide a webapp ... http://ant.apache.org/antlibs?uri=org.apache.ant.antunitversion=2 Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto download of antlibs
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/package.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. Am I wrong? Xavier Or we provide a webapp ... http://ant.apache.org/antlibs?uri=org.apache.ant.antunitversion=2 Jan - 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]
Re: auto download of antlibs
On Fri, 4 May 2007, Peter Reilly [EMAIL PROTECTED] wrote: On 5/4/07, Stefan Bodewig [EMAIL PROTECTED] wrote: On Fri, 04 May 2007, Steve Loughran [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 - I know the projects page, and I know that sometimes we are a bit sloppy in updating it, even if people send in patches. At one point we started to recommend that people use the Wiki instead. Using the Wiki is fine as long as the content is processed by humans, but it is unusable for automated processing. of course this raises the issues of version. One may not want the lastest version of a particular antlib. Could be a fragment identifier or an appended XPath or something like that antlib:org.apache.ant.antunit#1.1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r535314 - in /ant/core/trunk: CONTRIBUTORS WHATSNEW contributors.xml
Author: peterreilly Date: Fri May 4 09:19:35 2007 New Revision: 535314 URL: http://svn.apache.org/viewvc?view=revrev=535314 Log: Bugzilla 42334: System properties may be none string objects Modified: ant/core/trunk/CONTRIBUTORS ant/core/trunk/WHATSNEW ant/core/trunk/contributors.xml Modified: ant/core/trunk/CONTRIBUTORS URL: http://svn.apache.org/viewvc/ant/core/trunk/CONTRIBUTORS?view=diffrev=535314r1=535313r2=535314 == Binary files - no diff available. Modified: ant/core/trunk/WHATSNEW URL: http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?view=diffrev=535314r1=535313r2=535314 == --- ant/core/trunk/WHATSNEW (original) +++ ant/core/trunk/WHATSNEW Fri May 4 09:19:35 2007 @@ -68,6 +68,8 @@ * -autoproxy turns Java1.5+ automatic proxy support on. Bugzilla 41904 +* handle null result of system getProperty(). Bugzilla 42334. + Other changes: -- Modified: ant/core/trunk/contributors.xml URL: http://svn.apache.org/viewvc/ant/core/trunk/contributors.xml?view=diffrev=535314r1=535313r2=535314 == --- ant/core/trunk/contributors.xml (original) +++ ant/core/trunk/contributors.xml Fri May 4 09:19:35 2007 @@ -57,6 +57,10 @@ /name name firstAntoine/first +lastBaudoux/last + /name + name +firstAntoine/first lastLevy-Lambert/last /name name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42334] - PropertyHelper.setProperty() throws NullPointerException when the property value is not a String
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42334. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42334 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.7.1 --- Additional Comments From [EMAIL PROTECTED] 2007-05-04 09:25 --- I am not too sure that it correct to have non string values for system properties. It is of course possible to set them (since Properties extends Hashtable), but it does break the contract of system properties. In the javadoc for java.lang.Properties, the following is stated Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object. Their use is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The setProperty method should be used instead. If the store or save method is called on a compromised Properties object that contains a non-String key or value, the call will fail. However, as it is possible to encounter such invalid uses, the ant code has been modified and will be available in ant 1.7.1 Thanks for the Bug Report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42334] - PropertyHelper.setProperty() throws NullPointerException when the property value is not a String
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42334. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42334 --- Additional Comments From [EMAIL PROTECTED] 2007-05-04 12:52 --- thanks for the quick fix! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project test-ant (in module ant) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project test-ant has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - test-ant : Java based build tool Full details are available at: http://vmgump.apache.org/gump/public/ant/test-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/ant/test-ant/gump_work/build_ant_test-ant.html Work Name: build_ant_test-ant (Type: Build) Work ended in a state of : Failed Elapsed: 11 mins 59 secs Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtest.haltonfailure=false -Dant.home=/usr/local/gump/public/workspace/ant/dist run-tests [Working Directory: /usr/local/gump/public/workspace/ant] CLASSPATH:
[EMAIL PROTECTED]: Project test-ant-no-xerces (in module ant) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project test-ant-no-xerces has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - test-ant-no-xerces : Java based build tool Full details are available at: http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/gump_work/build_ant_test-ant-no-xerces.html Work Name: build_ant_test-ant-no-xerces (Type: Build) Work ended in a state of : Failed Elapsed: 18 mins 15 secs Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtest.haltonfailure=false -Dant.home=/usr/local/gump/public/workspace/ant/dist run-tests [Working Directory: /usr/local/gump/public/workspace/ant] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/build/testcases:/usr/local/gump/public/workspace/ant/src/tests/junit:/usr/local/gump/public/workspace/ant/src/etc/testcases:/usr/local/gump/public/workspace/ant/build/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-javamail.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jsch.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-antlr.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/usr/local/gump/public/workspace/ant/build/lib/ant.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jai.jar:/usr/local/gump/packages/antlr-2.7.6/antlr.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04052007.jar:/usr/local/gump/public/workspace/jakarta-commons/net/dist/commons-net-04052007.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/packages/bcel-5.2/bcel-5.2.jar:/usr/local/gump/public/workspace/jakarta-bsf/build/lib/bsf.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-04052007.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-04052007.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-04052007.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jdepend-2.6/lib/jdepend.jar:/usr/local/gump/packages/jsch/jsch-0.1.28.jar:/usr/local/gump/public/workspace/xml-stylebook/bin/stylebook-1.0-b3_xalan-2.jar:/usr/local/gump/public/workspace/ant-antlibs/antunit/build/ant-antunit-04052007.jar:/usr/local/gump/public/workspace/junit/dist/junit-04052007.jar:/usr/local/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-compiler.jar:/usr/local/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-runtime.jar:/usr/local/gump/public/workspace/xml-commons/java/build/which.jar:/usr/local/gump/public/workspace/rhino/build/rhino_04052007/js.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-04052007.jar - [au:antunit] Target:
