Re: svn commit: r549986 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Noticed the call of toString() on a String during the huntdown of what in beanutils broke the betwixt tests. (in the TestObjectStringConverters) The commit was a bit premature probably, although this is most (read most, so not all) of the time faster that calling toString() on a String. Will revert it (after some sleep) if that is what you are asking (code is more readable without the addition, agreed). Sorry was grmupy earlier - I leave it up to you. No problem, I kind of deserved that response with that commit :) If I am absolutely certain about a possible performance gain, I'll leave it in else I will revert it. Significant performance gain :) Definitely a gain, doubt it makes any real difference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons is TLP
Don't go the subtask route. Keep it all on the one issue as TLP Admin and Joe'll take care of things. Hen On 6/22/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: There is a Velocity JIRA Issue with a lot of subtasks that basically has everything that is needed/can be done for a new TLP. Scott cloned it for Turbine, so it is TRB-44 and INFRA-1249. These might be good starting points. Best regards Henning Torsten Curdt schrieb: On 21.06.2007, at 00:57, Martin van den Bemt wrote: Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. ...so where do we start with the TLP move is the question :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine Save the cheerleader. Save the world. - 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]
Re: svn commit: r549986 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Noticed the call of toString() on a String during the huntdown of what in beanutils broke the betwixt tests. (in the TestObjectStringConverters) The commit was a bit premature probably, although this is most (read most, so not all) of the time faster that calling toString() on a String. Will revert it (after some sleep) if that is what you are asking (code is more readable without the addition, agreed). Sorry was grmupy earlier - I leave it up to you. No problem, I kind of deserved that response with that commit :) If I am absolutely certain about a possible performance gain, I'll leave it in else I will revert it. Another questions (probably related to BEANUTILS-258) : The failing gump of betwixt is related to the changes you made to ConvertUtilsBean.convert(Object). In beanutils 1.7 a default lookup is done for the type String.class and in the new code this is just the case when no converter can be found for the sourcetype, which makes the new beanutils code not a drop in replacement of the old one and not backward compatible. I will see if I can run the beanutils 1.7 testcases against trunk tomorrow (they should pass, or am I being simplistic here?) Was this breakage intended and what are your thoughts on how to handle this ? I'm not familiar with betwixt - but I will look at this - hopefully sometme this weekend. I'll see if I can make a simple testcase which shows the problem (so you don't have to dig into betwixt itself). We currently have 24 tests failing with beanutils trunk.. I had a quick look at one of the failing tests and understand the issue with that one - I'll look at the rest and write something up later. Niall Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r549986 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Thanx.. Mvgr, Martin Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Noticed the call of toString() on a String during the huntdown of what in beanutils broke the betwixt tests. (in the TestObjectStringConverters) The commit was a bit premature probably, although this is most (read most, so not all) of the time faster that calling toString() on a String. Will revert it (after some sleep) if that is what you are asking (code is more readable without the addition, agreed). Sorry was grmupy earlier - I leave it up to you. No problem, I kind of deserved that response with that commit :) If I am absolutely certain about a possible performance gain, I'll leave it in else I will revert it. Another questions (probably related to BEANUTILS-258) : The failing gump of betwixt is related to the changes you made to ConvertUtilsBean.convert(Object). In beanutils 1.7 a default lookup is done for the type String.class and in the new code this is just the case when no converter can be found for the sourcetype, which makes the new beanutils code not a drop in replacement of the old one and not backward compatible. I will see if I can run the beanutils 1.7 testcases against trunk tomorrow (they should pass, or am I being simplistic here?) Was this breakage intended and what are your thoughts on how to handle this ? I'm not familiar with betwixt - but I will look at this - hopefully sometme this weekend. I'll see if I can make a simple testcase which shows the problem (so you don't have to dig into betwixt itself). We currently have 24 tests failing with beanutils trunk.. I had a quick look at one of the failing tests and understand the issue with that one - I'll look at the rest and write something up later. Niall Mvgr, Martin - 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]
[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) 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 commons-betwixt has an issue affecting its community integration. This issue affects 7 projects, and has been outstanding for 60 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-betwixt : Commons Betwixt Package - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb-from-packages-1-0-release : ObjectRelationalBridge - maven-bootstrap : Project Management Tools - test-ojb-from-packages-1-0-release : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-betwixt-24062007.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html Work Name: build_jakarta-commons_commons-betwixt (Type: Build) Work ended in a state of : Failed Elapsed: 3 mins 3 secs Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true -Dant.build.clonevm=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 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-24062007 -Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24062007.jar:/usr/local/gump/public/workspace/junit/dist/junit-24062007.jar - [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: value=null [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: version=3 [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: Names: [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: 0: version-from=2 [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: No attribute Version until [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy suppress [junit] INFO: Showing element [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO: Written: [junit] VersioningTestData attribute1=attributevalue1 [junit] element1elementvalue1/element1 [junit] element2elementvalue2/element2 [junit] /VersioningTestData [junit] [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO: testWrite1() complete [junit] - ---
[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) 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 commons-betwixt has an issue affecting its community integration. This issue affects 7 projects, and has been outstanding for 60 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-betwixt : Commons Betwixt Package - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb-from-packages-1-0-release : ObjectRelationalBridge - maven-bootstrap : Project Management Tools - test-ojb-from-packages-1-0-release : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-betwixt-24062007.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html Work Name: build_jakarta-commons_commons-betwixt (Type: Build) Work ended in a state of : Failed Elapsed: 3 mins 3 secs Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true -Dant.build.clonevm=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 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-24062007 -Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24062007.jar:/usr/local/gump/public/workspace/junit/dist/junit-24062007.jar - [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: value=null [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: version=3 [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: Names: [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: 0: version-from=2 [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: No attribute Version until [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.VersioningStrategy suppress [junit] INFO: Showing element [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO: Written: [junit] VersioningTestData attribute1=attributevalue1 [junit] element1elementvalue1/element1 [junit] element2elementvalue2/element2 [junit] /VersioningTestData [junit] [junit] Jun 24, 2007 4:28:31 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO: testWrite1() complete [junit] - ---
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) 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 commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 15 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-24062007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24062007.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/xmlunit/build/lib/xmlunit-24062007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.startElement(pNamespaceURI, pLocalName, pQName, pAttr); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:273: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.endElement(pNamespaceURI, pLocalName, pQName); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:282: cannot find symbol [javac] symbol : method getResult() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] org.apache.ws.jaxme.examples.misc.address.AddressType _1 = (org.apache.ws.jaxme.examples.misc.address.AddressType) getResult(); [javac]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) 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 commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 15 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-24062007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24062007.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/xmlunit/build/lib/xmlunit-24062007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.startElement(pNamespaceURI, pLocalName, pQName, pAttr); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:273: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.endElement(pNamespaceURI, pLocalName, pQName); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:282: cannot find symbol [javac] symbol : method getResult() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] org.apache.ws.jaxme.examples.misc.address.AddressType _1 = (org.apache.ws.jaxme.examples.misc.address.AddressType) getResult(); [javac]
Re: [VOTE] Release commons-sandbox-parent 1
Rahul Akolkar wrote: On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more comfortable), especially given that we are *not* releasing any sandbox jars. snip/ I appreciate you taking the time to elaborate. I am not impressed by any of these benefits (I'm not trying to be curt, I don't know how else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. So I stepped up to do the release. If I don't mind doing the job - why should you care? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) 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 commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 40 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24062007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) 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 commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 40 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24062007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more comfortable), especially given that we are *not* releasing any sandbox jars. snip/ I appreciate you taking the time to elaborate. I am not impressed by any of these benefits (I'm not trying to be curt, I don't know how else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. So I stepped up to do the release. If I don't mind doing the job - why should you care? the problem is that if you try to check out and build one of the sandbox components it won't work, you'd need to checkout the whole sandbox just for one of them just to get the parent. I think is not a big deal and will make the life of people trying the sandbox components easier -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons is TLP
Yes, but it *still* has a check list of all things to do (as subtasks). You don't need to clone it but you get an idea what a TLP can potentially have (e.g. a lot of TLPs did not know about the Solaris zones). Best regards Henning On Sat, 2007-06-23 at 23:33 -0700, Henri Yandell wrote: Don't go the subtask route. Keep it all on the one issue as TLP Admin and Joe'll take care of things. Hen On 6/22/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: There is a Velocity JIRA Issue with a lot of subtasks that basically has everything that is needed/can be done for a new TLP. Scott cloned it for Turbine, so it is TRB-44 and INFRA-1249. These might be good starting points. Best regards Henning Torsten Curdt schrieb: On 21.06.2007, at 00:57, Martin van den Bemt wrote: Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. ...so where do we start with the TLP move is the question :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/23/07, Dennis Lundberg [EMAIL PROTECTED] wrote: This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. Since you have a policy against releasing sandbox components, why not just deploy snapshots of the sandbox parent pom, and advance to the next snapshot version (without a release) when there is a change? I guess the issue there is that you then have to add the snapshot repo explicitly just to *build* a sandbox component or generate its web site. We want to force people to do that if they *depend* on sandbox jars, but just building a sandbox component should not require it IMO. snip/ And it doesn't require that to build either -- install the parent. I suspect anyone who has used m2 even minimally is aware of the bootstrapping problems with development builds and how to solve them. For everyone else (and I'm sure we will get questions), the sandbox components should have 'install parent pom' as step 0 of their 'building' pages. I guess that's what I see as the problem. IMO we should strive to make our components as easy to build as possible and this should apply to the sandbox as well as proper. Having to separately download, build and install the parent (correct me if I am wrong here, though if I am it sort of illustrates my point ;-) is a needless PITA for those trying to build a sandbox m2 component from source. Maven is supposed to make building easier and admittedly sometimes it does not. This is a case where needless futzing to get a build to work could be avoided by just publishing the parent so a straight build from the checked out sandbox component source can work. It is a maven pet peeve of mine that in some cases special local incantations have to be performed to get a build to work. I like to do everything possible to eliminate that. The site is also an issue. For better or for worse, site extensibility is tied to pom inheritance (again, correct me if I am wrong), so having a stable and consistent sandbox site build depends on having the sandbox parent POM available. Again, local build-and-install can workaround this, but why force people to do that and why give up consistency (whatever random svn grab is used will determine what shows up)? I guess I also agree with Dennis that I fail to see the negatives. Regarding the recurring busy work this is a do-ocracy and Dennis is stepping up to do this release. I will also help out as needed to maintain this POM. Phil -Rahul - 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]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more comfortable), especially given that we are *not* releasing any sandbox jars. snip/ I appreciate you taking the time to elaborate. I am not impressed by any of these benefits (I'm not trying to be curt, I don't know how else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. snip/ See line below, and less importantly, some comments above. I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. snap/ imagine? I can only go by reasons stated in this thread (Carlos' and Phil's subsequent posts do not have a new reason IMO). So I stepped up to do the release. If I don't mind doing the job - why should you care? snap/ Because this is a Commons release. Because (as a more general statement beyond the ASF workings) I believe that merely having someone available to do something, does not by itself, make doing that thing worthwhile. Because (in terms of the ASF workings) do-ocracies do not imply that others should not care about what you are doing when its about releasing artifacts. Because we will have to: * Release periodically - Needs process cycles: RMs, votes (thanks for your cycles on this one) - Who knows how often this will have to happen (lesser the better) * Update all sandbox component POMs to keep parent versions in sync etc. I vote: -0 (non-binding) -Rahul -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
Rahul Akolkar wrote: On 6/24/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more comfortable), especially given that we are *not* releasing any sandbox jars. snip/ I appreciate you taking the time to elaborate. I am not impressed by any of these benefits (I'm not trying to be curt, I don't know how else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. snip/ See line below, and less importantly, some comments above. I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. snap/ imagine? I can only go by reasons stated in this thread (Carlos' and Phil's subsequent posts do not have a new reason IMO). Here is the message that made me start this thread. http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200706.mbox/[EMAIL PROTECTED] Apparently he is working on commons CSV, so if releasing this pom can help him do that then it's a Good Thing TM. It might even help CSV to get promoted out of the sandbox. So I stepped up to do the release. If I don't mind doing the job - why should you care? snap/ Because this is a Commons release. Because (as a more general statement beyond the ASF workings) I believe that merely having someone available to do something, does not by itself, make doing that thing worthwhile. Because (in terms of the ASF workings) do-ocracies do not imply that others should not care about what you are doing when its about releasing artifacts. You misread my previous comment. I was not talking about *what* is being done, but *who* is doing it. You said that releasing the sandbox pom will require work, meaning someone has to do it. I then said that I'll do it. Can we just leave it at that. If we focus on *what* is being done instead. Can you tell me what is wrong with releasing the sandbox parent? Besides the fact that it requires someone has to do the actual work. Because we will have to: * Release periodically Not necessarily. The consensus when we started with Maven 2 poms was that we try to keep the parent(s) stable. Try something out in a component first and it's deemed good for all, then we'll move it to the parent. In my opinion the parent defines the common build process that all components should use. And that should not change that often. - Needs process cycles: RMs, votes (thanks for your cycles on this one) Like I said I'm volunteering to be RM for this release. If you don't have the cycles to check the release, you are perfectly entitled to refrain from voting. - Who knows how often this will have to happen (lesser the better) Agreed. * Update all sandbox component POMs to keep parent versions in sync etc. Again this doesn't have to be a lot of work. Once we get the first release of the sandbox pom out, it is necessary to update the poms of all sandbox components at least once. Again I'm volunteering here. I vote: -0 (non-binding) -Rahul -- Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Invite Rahul Akolkar to join the Apache Commons PMC
Its been +72 hours and the vote to invite Rahul Akolkar to join the Apache Commons PMC has passed with 15 +1 votes (14 binding) and no other votes from the following people: Henri Yandell Oliver Heger Niall Pemberton Luc Maisonobe Phil Steitz Martin van den Bemt Dion Gillard Jörg Schaible Torsten Curdt Dennis Lundberg Mario Ivankovits Stephen Colebourne Joerg Pietschmann Rory Winston Bechir Achouri Niall On 6/21/07, Niall Pemberton [EMAIL PROTECTED] wrote: Rahul Akolkar is an existing Jakarta PMC member and Commons Committer. He was against the proposal for Commons to become a TLP. Since that vote passed and the Apache Board has now passed the resolution for Commons to become a TLP I would like to invite Rahul to join the new Apache Commons PMC. It would be a tragedy IMO if we lose valuable members of the Commons Community just because they were originally against the TLP proposal. [ ] +1, don't let Rahul get away - lets try to get him to join the new PMC [ ] -1, no leave him out Niall P.S. Anyone else in the same situation, then I suggest we do the same - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Invitation to join the Apache Commons PMC
Hi Rahul, You've been nominated to become a part of the Apache Commons PMC and the vote has passed. Would you be interested in accepting the nomination? We understand that you were not in favour of the Commons TLP but, since the board has now passed the Commons resolution, hope that you still want to be involved with Commons and will accept this nomination -Niall, on behalf of the Commons PMC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Invitation to join the Apache Commons PMC
Hi Simon, You've been nominated to become a part of the Apache Commons PMC and the vote has passed. Would you be interested in accepting the nomination? We understand that you were not in favour of the Commons TLP but, since the board has now passed the Commons resolution, hope that you still want to be involved with Commons and will accept this nomination -Niall, on behalf of the Commons PMC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 23.06.2007, at 18:59, Rahul Akolkar wrote: On 6/23/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. IMO that's not very pragmatic. I think we would want to lower the barrier and get people involved. Providing a POM will make builds easier for the people that we want to attract. What I am failing to understand is what the fuzz is about. It's a POM ...it's metadata - not an artifact. No code! So here is my +1 for the release. +1 to what Torsten says and +1 to the release Niall cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 23.06.2007, at 18:59, Rahul Akolkar wrote: On 6/23/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. IMO that's not very pragmatic. I think we would want to lower the barrier and get people involved. Providing a POM will make builds easier for the people that we want to attract. What I am failing to understand is what the fuzz is about. It's a POM ...it's metadata - not an artifact. No code! So here is my +1 for the release. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Invite Simon Kitching to join the Apache Commons PMC
Its been +72 hours and the vote to invite Simon Kitching to join the Apache Commons PMC has passed with 15 +1 votes (13 binding) and no other votes from the following people: Henri Yandell Oliver Heger Niall Pemberton Luc Maisonobe Phil Steitz Martin van den Bemt Dion Gillard Jörg Schaible Torsten Curdt Dennis Lundberg Mario Ivankovits Stephen Colebourne Jeanfrancois Arcand Joerg Pietschmann Bechir Achouri Niall On 6/21/07, Niall Pemberton [EMAIL PROTECTED] wrote: Simon Kitching is an existing Jakarta PMC member and Commons Committer. He was against the proposal for Commons to become a TLP. Since that vote passed and the Apache Board has now passed the resolution for Commons to become a TLP I would like to invite Simon to join the new Apache Commons PMC. It would be a tragedy IMO if we lose valuable members of the Commons Community just because they were originally against the TLP proposal. [ ] +1, don't let Simon get away - lets try to get him to join the new PMC [ ] -1, no leave him out Niall P.S. Anyone else in the same situation, then I suggest we do the same - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-343) Validate: Throw NullArgumentException
Validate: Throw NullArgumentException - Key: LANG-343 URL: https://issues.apache.org/jira/browse/LANG-343 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Paul Benedict Fix For: 2.3.1 Validate methods should throw NullArgumentException on detecting null, not just IllegalArgumentException (its superclass) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r550285 - in /jakarta/commons/proper/math/trunk: src/java/org/apache/commons/math/stat/inference/ src/test/org/apache/commons/math/stat/inference/ xdocs/
Author: psteitz Date: Sun Jun 24 14:10:19 2007 New Revision: 550285 URL: http://svn.apache.org/viewvc?view=revrev=550285 Log: Added two-sample (binned comparison) ChiSquare test JIRA: MATH-160 Thanks to: Matthias Hummel Modified: jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/ChiSquareTest.java jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/ChiSquareTestImpl.java jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/TestUtils.java jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/stat/inference/ChiSquareTestTest.java jakarta/commons/proper/math/trunk/xdocs/changes.xml Modified: jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/ChiSquareTest.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/ChiSquareTest.java?view=diffrev=550285r1=550284r2=550285 == --- jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/ChiSquareTest.java (original) +++ jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/ChiSquareTest.java Sun Jun 24 14:10:19 2007 @@ -211,4 +211,118 @@ */ boolean chiSquareTest(long[][] counts, double alpha) throws IllegalArgumentException, MathException; + +/** + * pComputes a + * a href=http://www.itl.nist.gov/div898/software/dataplot/refman1/auxillar/chi2samp.htm; + * Chi-Square two sample test statistic/a comparing bin frequency counts + * in codeobserved1/code and codeobserved2/code. The + * sums of frequency counts in the two samples are not required to be the + * same. The formula used to compute the test statistic is/p + * code + * sum;[(K * observed1[i] - observed2[i]/K)sup2/sup / (observed1[i] + observed2[i])] + * /code where + * br/codeK = sqrt;[sum(observed2 / sum;(observed1)]/code + * /p + * pThis statistic can be used to perform a Chi-Square test evaluating the null hypothesis that + * both observed counts follow the same distribution. + * p + * strongPreconditions/strong: ul + * liObserved counts must be non-negative. + * /li + * liObserved counts for a specific bin must not both be zero. + * /li + * liObserved counts for a specific sample must not all be 0. + * /li + * liThe arrays codeobserved1/code and codeobserved2/code must have the same length and + * their common length must be at least 2. + * /li/ulp + * If any of the preconditions are not met, an + * codeIllegalArgumentException/code is thrown. + * + * @param observed1 array of observed frequency counts of the first data set + * @param observed2 array of observed frequency counts of the second data set + * @return chiSquare statistic + * @throws IllegalArgumentException if preconditions are not met + */ +double chiSquareDataSetsComparison(long[] observed1, long[] observed2) + throws IllegalArgumentException; + +/** + * pReturns the iobserved significance level/i, or a href= + * http://www.cas.lancs.ac.uk/glossary_v1.1/hyptest.html#pvalue; + * p-value/a, associated with a Chi-Square two sample test comparing + * bin frequency counts in codeobserved1/code and + * codeobserved2/code. + * /p + * pThe number returned is the smallest significance level at which one + * can reject the null hypothesis that the observed counts conform to the + * same distribution. + * /p + * pSee [EMAIL PROTECTED] #chiSquareDataSetsComparison(long[], long[]) for details + * on the formula used to compute the test statistic. The degrees of + * of freedom used to perform the test is one less than the common length + * of the input observed count arrays. + * /p + * strongPreconditions/strong: ul + * liObserved counts must be non-negative. + * /li + * liObserved counts for a specific bin must not both be zero. + * /li + * liObserved counts for a specific sample must not all be 0. + * /li + * liThe arrays codeobserved1/code and codeobserved2/code must + * have the same length and + * their common length must be at least 2. + * /li/ulp + * If any of the preconditions are not met, an + * codeIllegalArgumentException/code is thrown. + * + * @param observed1 array of observed frequency counts of the first data set + * @param observed2 array of observed frequency counts of the second data set + * @return p-value + * @throws IllegalArgumentException if preconditions are not met + * @throws MathException if an error occurs computing the p-value + */ +double chiSquareTestDataSetsComparison(long[] observed1, long[] observed2) + throws IllegalArgumentException,
[jira] Resolved: (MATH-160) Chi-Square Test for Comparing two binned Data Sets
[ https://issues.apache.org/jira/browse/MATH-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-160. -- Resolution: Fixed Applied a modified version of the patch, along with test cases, verified against DATAPLOT Modifications: * Changed input array data type to long[]. This is consistent with other ChiSquare tests and with the specification of the test (i.e., it is not clear what floats as arguments would mean) * Added weighting as specified in the NIST reference provided to adjust for possibly different bin sums for the two samples. Chi-Square Test for Comparing two binned Data Sets -- Key: MATH-160 URL: https://issues.apache.org/jira/browse/MATH-160 Project: Commons Math Issue Type: New Feature Reporter: Matthias Hummel Priority: Minor Fix For: 1.2 Attachments: commons-math.patch Current Chi-Square test implementation only supports standard Chi-Square testing with respect to known distribution. We needed testing for comparison of two sample data sets where the distribution can be unknown. For this case the Chi-Square test has to be computed in a different way so that both error contributions (one for each sample data set) are taken into account. See Press et. al, Numerical Recipes, Second Edition, formula 14.3.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-129) SFTP: proxy support with Username / Password
[ https://issues.apache.org/jira/browse/VFS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507733 ] Vasily Ivanov commented on VFS-129: --- I created a patch for this one. Attachments follow. Here is an example: FileSystemOptions opts = new FileSystemOptions(); SftpFileSystemConfigBuilder.getInstance().setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_HTTP); SftpFileSystemConfigBuilder.getInstance().setProxyHost(opts, someproxyhost); SftpFileSystemConfigBuilder.getInstance().setProxyPort(opts, someport); SftpFileSystemConfigBuilder.getInstance().setPorxyUserAuthenticator(opts, new StaticUserAuthenticator(null, proxyusername, proxypassword)); FileObject fo = VFS.getManager().resolveFile(someURI, opts); ... SFTP: proxy support with Username / Password Key: VFS-129 URL: https://issues.apache.org/jira/browse/VFS-129 Project: Commons VFS Issue Type: Improvement Environment: All Reporter: Graham Cruickshanks Priority: Minor SFTP proxy implementation does not have authenticator support, so can't tunnel through HTTP proxy via HTTPS port (443). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-129) SFTP: proxy support with Username / Password
[ https://issues.apache.org/jira/browse/VFS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Ivanov updated VFS-129: -- Attachment: SftpFileSystemConfigBuilder.java amended to accept proxy UserAuthenticator SFTP: proxy support with Username / Password Key: VFS-129 URL: https://issues.apache.org/jira/browse/VFS-129 Project: Commons VFS Issue Type: Improvement Environment: All Reporter: Graham Cruickshanks Priority: Minor Attachments: SftpClientFactory.java, SftpFileSystemConfigBuilder.java SFTP proxy implementation does not have authenticator support, so can't tunnel through HTTP proxy via HTTPS port (443). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-129) SFTP: proxy support with Username / Password
[ https://issues.apache.org/jira/browse/VFS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Ivanov updated VFS-129: -- Attachment: SftpClientFactory.java amended to allow HTTP and SOCKS5 proxy authentication SFTP: proxy support with Username / Password Key: VFS-129 URL: https://issues.apache.org/jira/browse/VFS-129 Project: Commons VFS Issue Type: Improvement Environment: All Reporter: Graham Cruickshanks Priority: Minor Attachments: SftpClientFactory.java, SftpFileSystemConfigBuilder.java SFTP proxy implementation does not have authenticator support, so can't tunnel through HTTP proxy via HTTPS port (443). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
