Re: [doc] Inspecting an RC
On 3/27/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: Anyone mind if I split the Things To Look For When Inspecting A Release Candidate section of http://jakarta.apache.org/commons/releases/prepare.html into its own page? And add in some bits about Phil's tools (I've been making modifications to them, hope you've been noticing Phil :) ). Theres are also these pages on the wiki that seem related: http://wiki.apache.org/jakarta-commons/ReleaseChecking http://wiki.apache.org/jakarta-commons/ReleaseShoppingList http://wiki.apache.org/jakarta-commons/CandidateQualityElection http://wiki.apache.org/jakarta-commons/SigningReleases Damn, I even went looking for them on the wiki and failed to see anything before discovering the stuff at the bottom of the release pages. Did I miss how to click to these, or did you use search? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Inspecting an RC
On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/27/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: Anyone mind if I split the Things To Look For When Inspecting A Release Candidate section of http://jakarta.apache.org/commons/releases/prepare.html into its own page? And add in some bits about Phil's tools (I've been making modifications to them, hope you've been noticing Phil :) ). Theres are also these pages on the wiki that seem related: http://wiki.apache.org/jakarta-commons/ReleaseChecking http://wiki.apache.org/jakarta-commons/ReleaseShoppingList http://wiki.apache.org/jakarta-commons/CandidateQualityElection http://wiki.apache.org/jakarta-commons/SigningReleases Damn, I even went looking for them on the wiki and failed to see anything before discovering the stuff at the bottom of the release pages. Did I miss how to click to these, or did you use search? I used the index page... http://wiki.apache.org/jakarta-commons/TitleIndex ...but in doing so I also found these: http://wiki.apache.org/jakarta-commons/CommonsCommitters http://wiki.apache.org/jakarta-commons/CommonsManual ...which seem like they should be the places to find these sorts of things. Niall Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Inspecting an RC
On 3/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/27/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: Anyone mind if I split the Things To Look For When Inspecting A Release Candidate section of http://jakarta.apache.org/commons/releases/prepare.html into its own page? And add in some bits about Phil's tools (I've been making modifications to them, hope you've been noticing Phil :) ). Theres are also these pages on the wiki that seem related: http://wiki.apache.org/jakarta-commons/ReleaseChecking http://wiki.apache.org/jakarta-commons/ReleaseShoppingList http://wiki.apache.org/jakarta-commons/CandidateQualityElection http://wiki.apache.org/jakarta-commons/SigningReleases Damn, I even went looking for them on the wiki and failed to see anything before discovering the stuff at the bottom of the release pages. Did I miss how to click to these, or did you use search? I used the index page... http://wiki.apache.org/jakarta-commons/TitleIndex Cool, not used that before. We've got a lot of crap haven't we? ...but in doing so I also found these: http://wiki.apache.org/jakarta-commons/CommonsCommitters http://wiki.apache.org/jakarta-commons/CommonsManual ...which seem like they should be the places to find these sorts of things. Yeah, CommonsManual is on my todo list. Or rather 'had enthusiasm for' list and now wondering if there are more incremental methods. Should we be thinking of flattening the old and stable wiki pages into the website at some point? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CopyStreamException on FTP Server
Hi All, Not sure if this is the right place to post this message. If its not, kindly direct me to the right mailing ID. We are using commons-net-1.2.2.jar to store retrieve a file from a FTP server. We use the FTPClient of this jar. When our code tries to store the File on FTP Server it fails giving this error: org.apache.commons.net.io.CopyStreamException: IOException caught while copying. Part of the code storing file is as follows : ftpclient.setFileType(FTP.BINARY_FILE_TYPE); status = ftpclient.storeFile(serverfilenm, fis); Moreover this doesn't happen for all the files, but only for few files. Has anyone ever faced this before? What could be the cause for this? Any views on this would be helpful. Thanks. Khyati Your only obligation in any lifetime is to be true to yourself . - Richard Bach ForwardSourceID:NT00018D0A ~~~Disclaimer~~ This e-mail contains confidential information and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended addressee, please inform the sender immediately, delete the e-mail and do not copy, disseminate, distribute, store, print or deliver this e-mail or information therein to anybody. The sender and the Company are not liable for any errors or omissions in this e-mail or for any claims, losses, damages arising out of this e-mail and information contained therein. ~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-28032006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - test:test: [junit] Running org.apache.commons.id.serial.PrefixedAlphanumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.47 sec [junit] Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.488 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.477 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.797 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.519 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.481 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.538 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.629 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.546 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.608 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.689 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.67 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.513 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.456 sec
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-28032006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - test:test: [junit] Running org.apache.commons.id.serial.PrefixedAlphanumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.47 sec [junit] Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.488 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.477 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.797 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.519 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.481 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.538 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.629 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.546 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.608 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.689 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.67 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.513 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.456 sec
[EMAIL PROTECTED]: Project commons-chain (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-chain has an issue affecting its community integration. This issue affects 16 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-chain : GoF Chain of Responsibility pattern - commons-jelly-tags-quartz : Commons Jelly - fulcrum-quartz : Services Framework - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-velocity-tools : Velocity-Tools project - myfaces : JavaServer(tm) Faces implementation - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-bridges-struts : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - quartz : Job Scheduler - struts-action : Model 2 Model-View-Controller framework for Servlets and JSP - struts-el : Model 2 Model-View-Controller framework for Servlets and JSP - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - struts-taglib : Model 2 Model-View-Controller framework for Servlets and JSP - struts-tiles : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-chain/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-chain-28032006.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-chain/gump_work/build_jakarta-commons_commons-chain.html Work Name: build_jakarta-commons_commons-chain (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: 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 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-chain-28032006 -f build.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/chain] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/classes:/usr/local/gump/public/workspace/jakarta-commons/chain/target/test-classes:/usr/local/gump/packages/jsf-1_1_01/lib/jsf-api.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/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.294 sec [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.294 sec [junit] Testcase: testPristine took 0.041 sec [junit] Testcase: testReadOnly took 0.002 sec [junit] Testcase: testReadWrite took 0 sec [junit] Testcase: testWriteOnly took 0.002 sec [junit] Testcase: testAttributes took 0.001 sec [junit] Testcase: testContains took 0.001 sec [junit] Testcase: testEquals took 0.012 sec [junit] Testcase: testKeySet took 0.001 sec [junit] Testcase: testPutAll took 0 sec [junit] Testcase: testSeriaization took 0.052 sec [junit] Running org.apache.commons.chain.web.ChainResourcesTestCase [junit] Testsuite: org.apache.commons.chain.web.ChainResourcesTestCase
[EMAIL PROTECTED]: Project commons-chain (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-chain has an issue affecting its community integration. This issue affects 16 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-chain : GoF Chain of Responsibility pattern - commons-jelly-tags-quartz : Commons Jelly - fulcrum-quartz : Services Framework - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-velocity-tools : Velocity-Tools project - myfaces : JavaServer(tm) Faces implementation - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-bridges-struts : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - quartz : Job Scheduler - struts-action : Model 2 Model-View-Controller framework for Servlets and JSP - struts-el : Model 2 Model-View-Controller framework for Servlets and JSP - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - struts-taglib : Model 2 Model-View-Controller framework for Servlets and JSP - struts-tiles : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-chain/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-chain-28032006.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-chain/gump_work/build_jakarta-commons_commons-chain.html Work Name: build_jakarta-commons_commons-chain (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: 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 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-chain-28032006 -f build.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/chain] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/classes:/usr/local/gump/public/workspace/jakarta-commons/chain/target/test-classes:/usr/local/gump/packages/jsf-1_1_01/lib/jsf-api.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/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.294 sec [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.294 sec [junit] Testcase: testPristine took 0.041 sec [junit] Testcase: testReadOnly took 0.002 sec [junit] Testcase: testReadWrite took 0 sec [junit] Testcase: testWriteOnly took 0.002 sec [junit] Testcase: testAttributes took 0.001 sec [junit] Testcase: testContains took 0.001 sec [junit] Testcase: testEquals took 0.012 sec [junit] Testcase: testKeySet took 0.001 sec [junit] Testcase: testPutAll took 0 sec [junit] Testcase: testSeriaization took 0.052 sec [junit] Running org.apache.commons.chain.web.ChainResourcesTestCase [junit] Testsuite: org.apache.commons.chain.web.ChainResourcesTestCase
[EMAIL PROTECTED]: Project commons-jelly-tags-xml-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-xml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 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-xml-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build) Work ended in a state of : Failed Elapsed: 29 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] 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-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-xml-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-xml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 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-xml-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build) Work ended in a state of : Failed Elapsed: 29 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] 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-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit]
[EMAIL PROTECTED]: Project commons-latka (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-latka has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-latka : Functional Testing Suite Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-latka/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-latka.jar] identifier set to project name -DEBUG- Dependency on jaxen exists, no need to add for property jaxen.jar. -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes] -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-commons/latka/target/test-classes] -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-latka/gump_work/build_jakarta-commons_commons-latka.html Work Name: build_jakarta-commons_commons-latka (Type: Build) Work ended in a state of : Failed Elapsed: 8 secs Command Line: 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 -Djaxen.jar=/usr/local/gump/public/workspace/jaxen/target/jaxen-28032006.jar dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/latka] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes:/usr/local/gump/public/workspace/jakarta-commons/latka/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/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-28032006.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-28032006.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-28032006.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.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-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-28032006.jar - [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/latka/src/java/org/apache/commons/latka/servlet/ViewResponseServlet.java:44: warning: [deprecation] getInstance(java.lang.Class) in org.apache.log4j.Category has been deprecated [javac] public static final Category _log = Category.getInstance( [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/latka/src/java/org/apache/commons/latka/validators/BaseValidator.java:35: warning: [deprecation] getInstance(java.lang.Class) in org.apache.log4j.Category has been deprecated [javac] protected final Category _log = Category.getInstance(BaseValidator.class);
[EMAIL PROTECTED]: Project commons-latka (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-latka has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-latka : Functional Testing Suite Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-latka/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-latka.jar] identifier set to project name -DEBUG- Dependency on jaxen exists, no need to add for property jaxen.jar. -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes] -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-commons/latka/target/test-classes] -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-latka/gump_work/build_jakarta-commons_commons-latka.html Work Name: build_jakarta-commons_commons-latka (Type: Build) Work ended in a state of : Failed Elapsed: 8 secs Command Line: 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 -Djaxen.jar=/usr/local/gump/public/workspace/jaxen/target/jaxen-28032006.jar dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/latka] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/latka/target/classes:/usr/local/gump/public/workspace/jakarta-commons/latka/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/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-28032006.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-28032006.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-28032006.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.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-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-28032006.jar - [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/latka/src/java/org/apache/commons/latka/servlet/ViewResponseServlet.java:44: warning: [deprecation] getInstance(java.lang.Class) in org.apache.log4j.Category has been deprecated [javac] public static final Category _log = Category.getInstance( [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/latka/src/java/org/apache/commons/latka/validators/BaseValidator.java:35: warning: [deprecation] getInstance(java.lang.Class) in org.apache.log4j.Category has been deprecated [javac] protected final Category _log = Category.getInstance(BaseValidator.class);
[EMAIL PROTECTED]: Project commons-jelly-tags-html (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-html has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-28032006.jar] identifier set to project name -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/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/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-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] 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/cli/target/commons-cli-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-html (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-html has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-28032006.jar] identifier set to project name -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/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/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-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] 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/cli/target/commons-cli-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
[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 46 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. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -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: 15 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/jakarta-commons/cli/target/commons-cli-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [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) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit] at
[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 46 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. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -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: 15 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/jakarta-commons/cli/target/commons-cli-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [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) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit] at
Re: [doc] Inspecting an RC
+1 for splitting up the releases page as Hen suggests and also incorporating the relevant and durable content of the wiki pages below. Phil On 3/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/27/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: Anyone mind if I split the Things To Look For When Inspecting A Release Candidate section of http://jakarta.apache.org/commons/releases/prepare.html into its own page? And add in some bits about Phil's tools (I've been making modifications to them, hope you've been noticing Phil :) ). Theres are also these pages on the wiki that seem related: http://wiki.apache.org/jakarta-commons/ReleaseChecking http://wiki.apache.org/jakarta-commons/ReleaseShoppingList http://wiki.apache.org/jakarta-commons/CandidateQualityElection http://wiki.apache.org/jakarta-commons/SigningReleases Damn, I even went looking for them on the wiki and failed to see anything before discovering the stuff at the bottom of the release pages. Did I miss how to click to these, or did you use search? I used the index page... http://wiki.apache.org/jakarta-commons/TitleIndex ...but in doing so I also found these: http://wiki.apache.org/jakarta-commons/CommonsCommitters http://wiki.apache.org/jakarta-commons/CommonsManual ...which seem like they should be the places to find these sorts of things. Niall Hen - 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-jelly-tags-define-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-define-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] 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/cli/target/commons-cli-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536) [junit] Mar 28, 2006 4:27:44 AM org.apache.commons.jelly.expression.xpath.XPathExpression evaluate [junit] SEVERE: Error constructing xpath [junit] org.jaxen.XPathSyntaxException: Node-set expected [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:131) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:156) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-define-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-define-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] 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/cli/target/commons-cli-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-28032006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536) [junit] Mar 28, 2006 4:27:44 AM org.apache.commons.jelly.expression.xpath.XPathExpression evaluate [junit] SEVERE: Error constructing xpath [junit] org.jaxen.XPathSyntaxException: Node-set expected [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:131) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:156) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at
DO NOT REPLY [Bug 36962] - [vfs] Cannot used base root with FTP
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=36962. 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=36962 --- Additional Comments From [EMAIL PROTECTED] 2006-03-28 13:50 --- Can you please fix it. I mustn't use cache because I have frequent changes on my ftp, and I'm always cleaning the cache (performances leaks ?) and it may cause some bugs in my software if I forget to clean it somewhere... in getParent, Can't you test the equality of the .getName().getPath() instead of the equality of the instances ? This will avoid cache problem. -- 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]
Re: [all] Line width and such minutiae
On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Sandy McArthur [EMAIL PROTECTED] wrote: snip/ P.S.- [pool] code is quite hard to read with all that horizontal scrolling. Irrespective of the code already in place, maybe we should stick to a reasonable (80?) character line width for new code? The code I contribute to apache is code I wrote for pleasure. The code I contribute is in the form that was most pleasurable for me to write in. When contributing to a community code base, you also need to think about how approachable your code is to other contributors, many / most of whom may not currently be working on the project. I impose no restrictions on how others choose to write their code. If you wish to compensate me to write code differently or reject my contributions because of such trivial issues, that is fine. The ASL grants anyone the right reformat ASL licensed code however they see fit. I only request that I am not stripped of attribution for my contributions. snap/ The comment wasn't about imposing restrictions, that would never work anyway. Even while writing for pleasure, a lot of components still check for style (I think its valuable). The line width style criteria has some valid reasons, not the least of which is its accessibility implication that those more fortunate tend to not realize. So, I am implicitly -0 for any *new* commits that are needlessly and consistently too wide which indicates my personal preference (a -1 ofcourse would be an attempt to impose a restriction). And I will always respect your opinion, even if it doesn't match mine. Compensation never comes to my mind in face of any discussions on these mailing lists, that bit was a no-brainer. +1 - regarding style issues, we have been fairly consistent in the following: * When contributing code to an existing component, follow the style of the surrounding code * Decisions to change the coding style or set checkstyle / pmd / other rules for style checking are made by (lazy) consensus at the component level, with opinions of those actively working on the code having greatest weight * Separate reformatting commits from commits that change behavior and try to avoid extraneous diffs in commits. My personal preference is 80 column line widths, partly because this makes diffs readable. As a sidebar, since attribution got mentioned -- its an old, widely discussed topic at the ASF. Some of us believe that author tags in source code are a distraction (doesn't mean we want everyone to change their opinion). It has to do with issues arising out of how you define the least unit of work that warrants an author tag, the tedium of having to remember to add an author tag while applying a patch, and issues of fairness (should the author tags be ordered by size of contribution to the source file, name, chronology). A lot of older projects traditionally had author tags, so its more effort to discontinue, but for newer projects, I personally have begun to prefer the no author tags policy. Accordingly, I will likely -1 a patch to the [scxml] code if the author insists on having an author tag. And maybe that means [scxml] will miss out on some valuable contributions from talented folks purely for that reason, but that is perhaps the lesser of the two evils. Attribution then, gets handled via commit messages and the team page. All commit messages contain attribution as the case may be, and anyone who contributes any code -- be it a line or a million -- gets listed on the team page. +1 and search the archives for lots of discussion about why we should not be adding new @author tags. I find listening to the variety of opinions on almost all things here at the ASF makes me richer. And thats the kind of compensation that keeps us all coming back ;-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CopyStreamException on FTP Server
Hi All, Not sure if this is the right place to post this message. If its not, kindly direct me to the right mailing ID. We are using commons-net-1.2.2.jar to store retrieve a file from a FTP server. We use the FTPClient of this jar. When our code tries to store the File on FTP Server it fails giving this error: org.apache.commons.net.io.CopyStreamException: IOException caught while copying. Part of the code storing file is as follows : ftpclient.setFileType(FTP.BINARY_FILE_TYPE); status = ftpclient.storeFile(serverfilenm, fis); Moreover this doesn't happen for all the files, but only for few files. Has anyone ever faced this before? What could be the cause for this? Any views on this would be helpful. Thanks. Khyati Your only obligation in any lifetime is to be true to yourself . - Richard Bach ~~~Disclaimer~~ This e-mail contains confidential information and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended addressee, please inform the sender immediately, delete the e-mail and do not copy, disseminate, distribute, store, print or deliver this e-mail or information therein to anybody. The sender and the Company are not liable for any errors or omissions in this e-mail or for any claims, losses, damages arising out of this e-mail and information contained therein. ~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Sandy McArthur [EMAIL PROTECTED] wrote: snip/ P.S.- [pool] code is quite hard to read with all that horizontal scrolling. Irrespective of the code already in place, maybe we should stick to a reasonable (80?) character line width for new code? The code I contribute to apache is code I wrote for pleasure. The code I contribute is in the form that was most pleasurable for me to write in. When contributing to a community code base, you also need to think about how approachable your code is to other contributors, many / most of whom may not currently be working on the project. I impose no restrictions on how others choose to write their code. If you wish to compensate me to write code differently or reject my contributions because of such trivial issues, that is fine. The ASL grants anyone the right reformat ASL licensed code however they see fit. I only request that I am not stripped of attribution for my contributions. snap/ The comment wasn't about imposing restrictions, that would never work anyway. Even while writing for pleasure, a lot of components still check for style (I think its valuable). The line width style criteria has some valid reasons, not the least of which is its accessibility implication that those more fortunate tend to not realize. So, I am implicitly -0 for any *new* commits that are needlessly and consistently too wide which indicates my personal preference (a -1 ofcourse would be an attempt to impose a restriction). And I will always respect your opinion, even if it doesn't match mine. Compensation never comes to my mind in face of any discussions on these mailing lists, that bit was a no-brainer. +1 - regarding style issues, we have been fairly consistent in the following: * When contributing code to an existing component, follow the style of the surrounding code * Decisions to change the coding style or set checkstyle / pmd / other rules for style checking are made by (lazy) consensus at the component level, with opinions of those actively working on the code having greatest weight * Separate reformatting commits from commits that change behavior and try to avoid extraneous diffs in commits. My personal preference is 80 column line widths, partly because this makes diffs readable. As a sidebar, since attribution got mentioned -- its an old, widely discussed topic at the ASF. Some of us believe that author tags in source code are a distraction (doesn't mean we want everyone to change their opinion). It has to do with issues arising out of how you define the least unit of work that warrants an author tag, the tedium of having to remember to add an author tag while applying a patch, and issues of fairness (should the author tags be ordered by size of contribution to the source file, name, chronology). A lot of older projects traditionally had author tags, so its more effort to discontinue, but for newer projects, I personally have begun to prefer the no author tags policy. Accordingly, I will likely -1 a patch to the [scxml] code if the author insists on having an author tag. And maybe that means [scxml] will miss out on some valuable contributions from talented folks purely for that reason, but that is perhaps the lesser of the two evils. Attribution then, gets handled via commit messages and the team page. All commit messages contain attribution as the case may be, and anyone who contributes any code -- be it a line or a million -- gets listed on the team page. +1 and search the archives for lots of discussion about why we should not be adding new @author tags. I have searched some and the arguments don't hold water with me. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. I find listening to the variety of opinions on almost all things here at the ASF makes me richer. And thats the kind of compensation that keeps us all coming back ;-) -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/27/06, Sandy McArthur [EMAIL PROTECTED] wrote: snip/ P.S.- [pool] code is quite hard to read with all that horizontal scrolling. Irrespective of the code already in place, maybe we should stick to a reasonable (80?) character line width for new code? The code I contribute to apache is code I wrote for pleasure. The code I contribute is in the form that was most pleasurable for me to write in. When contributing to a community code base, you also need to think about how approachable your code is to other contributors, many / most of whom may not currently be working on the project. I impose no restrictions on how others choose to write their code. If you wish to compensate me to write code differently or reject my contributions because of such trivial issues, that is fine. The ASL grants anyone the right reformat ASL licensed code however they see fit. I only request that I am not stripped of attribution for my contributions. snap/ The comment wasn't about imposing restrictions, that would never work anyway. Even while writing for pleasure, a lot of components still check for style (I think its valuable). The line width style criteria has some valid reasons, not the least of which is its accessibility implication that those more fortunate tend to not realize. So, I am implicitly -0 for any *new* commits that are needlessly and consistently too wide which indicates my personal preference (a -1 ofcourse would be an attempt to impose a restriction). And I will always respect your opinion, even if it doesn't match mine. Compensation never comes to my mind in face of any discussions on these mailing lists, that bit was a no-brainer. +1 - regarding style issues, we have been fairly consistent in the following: * When contributing code to an existing component, follow the style of the surrounding code * Decisions to change the coding style or set checkstyle / pmd / other rules for style checking are made by (lazy) consensus at the component level, with opinions of those actively working on the code having greatest weight * Separate reformatting commits from commits that change behavior and try to avoid extraneous diffs in commits. My personal preference is 80 column line widths, partly because this makes diffs readable. As a sidebar, since attribution got mentioned -- its an old, widely discussed topic at the ASF. Some of us believe that author tags in source code are a distraction (doesn't mean we want everyone to change their opinion). It has to do with issues arising out of how you define the least unit of work that warrants an author tag, the tedium of having to remember to add an author tag while applying a patch, and issues of fairness (should the author tags be ordered by size of contribution to the source file, name, chronology). A lot of older projects traditionally had author tags, so its more effort to discontinue, but for newer projects, I personally have begun to prefer the no author tags policy. Accordingly, I will likely -1 a patch to the [scxml] code if the author insists on having an author tag. And maybe that means [scxml] will miss out on some valuable contributions from talented folks purely for that reason, but that is perhaps the lesser of the two evils. Attribution then, gets handled via commit messages and the team page. All commit messages contain attribution as the case may be, and anyone who contributes any code -- be it a line or a million -- gets listed on the team page. +1 and search the archives for lots of discussion about why we should not be adding new @author tags. I have searched some and the arguments don't hold water with me. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. All of us are proud of our contributions here. But the ASF is not about egos, and it is not about recognition. I don't know who came up with the phrase, but egoless programming is an appropriate term for the way we work. If you came here for the recognition, then I'm afraid you made a mistake. Perhaps we need to make a more prominent statement about author tags somewhere, for the benefit of potential future contributors. -- Martin Cooper I find listening to the variety of opinions on almost all things here at the ASF
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-28032006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - test:test: [junit] Running org.apache.commons.id.serial.PrefixedAlphanumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.449 sec [junit] Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.485 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.451 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.769 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.489 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.457 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.517 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.614 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.551 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.617 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.681 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.671 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.46 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.451 sec [junit] Running
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-28032006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-28032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-28032006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - test:test: [junit] Running org.apache.commons.id.serial.PrefixedAlphanumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.449 sec [junit] Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.485 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.451 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.769 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.489 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.457 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.517 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.614 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.551 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.617 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.681 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.671 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.46 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.451 sec [junit] Running
DO NOT REPLY [Bug 36529] - [lang] Fraction 0 to the zeroth power should throw an ArithmeticException
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=36529. 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=36529 --- Additional Comments From [EMAIL PROTECTED] 2006-03-28 21:21 --- Zero to the power of zero, though undefined, is often defined to be 1 for several reasons. See this entry in the sci.math FAQ: http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/ I would consider the current behaviour of returning 1 far more desirable than what is requested. Change resolution to WONTFIX? -- 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]
[vfs][compress] TAR Filesystem creation temp dir
Hello, I am running the VFS test suite. I have problems, so I do manual tests. In one of them, I try to parse the following URI (the file does exist) uri = tar:gz://Z:\\programming\\apache\\jakarta\\commons\\vfs\\target\ \test-data\\nested.tar.gz!/nested.tar/file1.txt; byy calling manager.resolveFile(uri); During the creation of a tar.gz file, you create the tar file. When you create a TAR Filesystem, it creates a temporary directory. You end up with a FileObject entry representing the tar file created in the VFS namespace. This entry represents a directory. Afterward, when you want to create the content of thye tar file, you first open it. At this time, you call createTarFile method in class TarFileSystem try to read a file on the (local) filesystem by using the following statement : new TarInputStream(new FileInputStream(file)); This leads to an exception because it tries to open a directory instead of a file. What is the good way ? Building the whole tar tree in a stream in which case the first part of the code is wrong (can be hard to solve since it is something that is not in the TAR provider). Or building the entries in a temporary location. In the later case, you have to have to handle the case of a non yet existing tar file and first decompress it internally if it exist. I think the first one is better.Bu I have to check this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: snip/ * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. or replace with a mock pool implementation (if possible) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Sandy McArthur [EMAIL PROTECTED] wrote: I have searched some and the arguments don't hold water with me. Main reasons I cba to put my name on stuff I touch or create nowadays: * Private emails asking questions, offering patches etc. It starts to add up. * It's an effort to put @author in. I'm lazy. Lots of names in one file does start to feel spammy. * It's pretty minor in terms of recognition. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. Until we decide as a community to remove the @author bits, you're welcome to keep adding them in. I'm pretty sure we've not made any community decisions as that thread would have stretched on for a long time. It's not a case of borg btw; the alternative to @author appears to be listing the people involved in a project somewhere. Might be interesting to do that per release :) Very Sesame St; Commons Lang 2.2 came to you via the work of . To refer directly to Rahul's some of us believe bit; I also believe that 50% of javadoc is a distraction to the code :) I doubt we're going to change that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Sandy McArthur [EMAIL PROTECTED] wrote: I have searched some and the arguments don't hold water with me. Main reasons I cba to put my name on stuff I touch or create nowadays: * Private emails asking questions, offering patches etc. It starts to add up. * It's an effort to put @author in. I'm lazy. Lots of names in one file does start to feel spammy. * It's pretty minor in terms of recognition. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. Until we decide as a community to remove the @author bits Hmm, I thought we'd made that decision some time ago. Am I spacing? , you're welcome to keep adding them in. I'm pretty sure we've not made any community decisions as that thread would have stretched on for a long time. It's not a case of borg btw; the alternative to @author appears to be listing the people involved in a project somewhere. Might be interesting to do that per release :) Very Sesame St; Commons Lang 2.2 came to you via the work of . We already list the developers on the component web sites. For Pool, for example: http://jakarta.apache.org/commons/pool/team-list.html -- Martin Cooper To refer directly to Rahul's some of us believe bit; I also believe that 50% of javadoc is a distraction to the code :) I doubt we're going to change that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Martin Cooper wrote: For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. Ah, the joy of a line width debate. My choice is a 80 character basic width extending to 120+ when it make it more readable. But in the big scheme of things, its not that important. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Sandy McArthur [EMAIL PROTECTED] wrote: I have searched some and the arguments don't hold water with me. Main reasons I cba to put my name on stuff I touch or create nowadays: * Private emails asking questions, offering patches etc. It starts to add up. * It's an effort to put @author in. I'm lazy. Lots of names in one file does start to feel spammy. * It's pretty minor in terms of recognition. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. Until we decide as a community to remove the @author bits Hmm, I thought we'd made that decision some time ago. Am I spacing? Probably not. I got sucked into the chair crap and lost my way. I probably missed the thread etc. If we have decided that, then I'm happy to script them all out (and into team list files etc). And we should probably make sure that we take care of disagreements now rather than later. , you're welcome to keep adding them in. I'm pretty sure we've not made any community decisions as that thread would have stretched on for a long time. It's not a case of borg btw; the alternative to @author appears to be listing the people involved in a project somewhere. Might be interesting to do that per release :) Very Sesame St; Commons Lang 2.2 came to you via the work of . We already list the developers on the component web sites. For Pool, for example: http://jakarta.apache.org/commons/pool/team-list.html Sorry, bad wording on my part. I rewrote that bit a few times and lost the project.xml and other ways in which it's already done because I was too interested in the idea of a list per release :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Line width and such minutiae
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 2:27 PM To: Jakarta Commons Developers List Subject: Re: [all] Line width and such minutiae On 3/28/06, Sandy McArthur [EMAIL PROTECTED] wrote: I have searched some and the arguments don't hold water with me. Main reasons I cba to put my name on stuff I touch or create nowadays: * Private emails asking questions, offering patches etc. It starts to add up. * It's an effort to put @author in. I'm lazy. Lots of names in one file does start to feel spammy. * It's pretty minor in terms of recognition. I'm proud of the code I've contributed and I think an @author tag is proper recognition. I feel strongly enough about this that I'd rather not contribute to apache at all than loose that recognition. We are not the Apache Borg. We are a group of individuals that enjoy programming. I am not willing to be assimilated and if the rest of apache has a problem with that then revoke my commit rights. Until we decide as a community to remove the @author bits, you're welcome to keep adding them in. I'm pretty sure we've not made any community decisions as that thread would have stretched on for a long time. Based on the February 18, 2004, Apache Software Foundation Board of Directors Meeting Minutes, author tags are discouraged. From http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004 _02_18.txt Although initiated due to the current efforts for Spam Assassin, the board discussed at length the issues and guidelines regarding copyright ownership for the ASF. It was agreed that all files should have 1 single copyright to the ASF. Copyrights extend to the work as a whole, and the ASF must have these. The use of the CHANGES files should note any history regarding copyrights and that the use of 'author' tags should be discouraged for this and other reasons. Gary It's not a case of borg btw; the alternative to @author appears to be listing the people involved in a project somewhere. Might be interesting to do that per release :) Very Sesame St; Commons Lang 2.2 came to you via the work of . To refer directly to Rahul's some of us believe bit; I also believe that 50% of javadoc is a distraction to the code :) I doubt we're going to change that. Hen - 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: [all] Line width and such minutiae
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Tuesday, March 28, 2006 3:02 PM To: Jakarta Commons Developers List Subject: Re: [all] Line width and such minutiae On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. This sounds to me like a problem with a particular diff tool. I do not think we should restrict our source code based on the limitations of /one/ tool. For those of us using Eclipse, this is not an issue since the tool (Eclipse) presents a nice user-interface that allows me to focus on the nature of the changes as opposed to the changes and the format the changes are given in. We use 120 at work. I think we got the idea from Jakarata Commons but I cannot find a link right now. Plenty of Commons projects use 120, so the number must come from some previous agreement. Gary -- Martin Cooper Hen - 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: r389631 - in /jakarta/commons/sandbox/scxml/trunk: ./ src/main/java/org/apache/commons/scxml/semantics/ src/test/java/org/apache/commons/scxml/ src/test/java/org/apache/commons/scxml/env/j
Author: rahul
Date: Tue Mar 28 15:50:38 2006
New Revision: 389631
URL: http://svn.apache.org/viewcvs?rev=389631view=rev
Log:
* Unnamed events are not ignored, came out of test cases from Heiko Eichberger
(Heiko dot Eichberger AT rsbick.rohde-schwarz DOT com).
* Add slightly modified versions of Heiko's tests to the Commons SCXML test
suite.
* Add Heiko to the contributors section in POM.
Added:
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/WizardsTest.java
(with props)
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/wizard-01.xml
(with props)
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/wizard-02.xml
(with props)
Modified:
jakarta/commons/sandbox/scxml/trunk/project.xml
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLTestSuite.java
Modified: jakarta/commons/sandbox/scxml/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/project.xml?rev=389631r1=389630r2=389631view=diff
==
--- jakarta/commons/sandbox/scxml/trunk/project.xml (original)
+++ jakarta/commons/sandbox/scxml/trunk/project.xml Tue Mar 28 15:50:38 2006
@@ -93,6 +93,9 @@
contributor
nameWendy Smoak/name
/contributor
+contributor
+ nameHeiko Eichberger/name
+/contributor
/contributors
dependencies
Modified:
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java?rev=389631r1=389630r2=389631view=diff
==
---
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
(original)
+++
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
Tue Mar 28 15:50:38 2006
@@ -602,9 +602,11 @@
Iterator i = eventOccurrences.iterator();
while (i.hasNext()) {
String evt = (String) i.next();
-if (evt == null || evt.equals(transEvent) //null for Standalone
-|| evt.startsWith(transEventDot)) {
-return true;
+if (evt == null) {
+continue; // Unnamed events
+} else if (evt.equals(transEvent)
+|| evt.startsWith(transEventDot)) {
+return true;
}
}
return false;
Modified:
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLTestSuite.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLTestSuite.java?rev=389631r1=389630r2=389631view=diff
==
---
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLTestSuite.java
(original)
+++
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLTestSuite.java
Tue Mar 28 15:50:38 2006
@@ -52,6 +52,7 @@
suite.addTest(SCXMLHelperTest.suite());
suite.addTest(StatusTest.suite());
suite.addTest(TriggerEventTest.suite());
+suite.addTest(WizardsTest.suite());
return suite;
}
}
Added:
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/WizardsTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/WizardsTest.java?rev=389631view=auto
==
---
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/WizardsTest.java
(added)
+++
jakarta/commons/sandbox/scxml/trunk/src/test/java/org/apache/commons/scxml/WizardsTest.java
Tue Mar 28 15:50:38 2006
@@ -0,0 +1,166 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.scxml;
+
+import java.net.URL;
Re: [all] Author tags [was Line width and such minutiae]
Henri Yandell wrote: If we have decided [to remove author tags], then I'm happy to script them all out (and into team list files etc). And we should probably make sure that we take care of disagreements now rather than later. Gary Gregory wrote: Based on the February 18, 2004, Apache Software Foundation Board of Directors Meeting Minutes, author tags are discouraged. AFAIR we haven't ever voted on this, as removing existing author tags is always been a touchy subject when brought up. At present, its a component-level choice. I believe that it is general practice in commons to refer to the author in commit comments, and to use the maven team list facility, but I could be wrong. Certainly [collections] still has author tags, although I had recently considered proposing their removal as I now find them a hassle. Sandy McArthur wrote: I have searched some and the arguments don't hold water with me. :-) Many things from lawyers and the board don't make sense ;-) I'm proud of the code I've contributed and I think an @author tag is proper recognition. I suppose that five years ago when I joined, I felt something similar. At that time author tags were allowed, so it wasn't a problem. Over time, that desire for such 'base' recognition has gone. IMHO, the true recognition is from the peers in your community. As a peer, I can say that we have already recognised your contributions so far (by voting you a committer for example). I personally also greatly appreciate the new life that you have instilled in both pool and dbcp. It is a balance though. Martin's 'egoless programming' comment is essentialy correct. I am here because I want to code, I want to learn, because I enjoy the community and I want to share. It is possible that I may benefit career-wise, or perhaps not. What I do know is that I don't feel any need to shout my contribution via an author tag - there are plenty of other outlets to mention the work I do (maven team-list, blog, Javalobby, the server side...) if and when I feel it appropriate. In summary however, I still think a board-level command 'no author tags' was a bit silly as it just created lots of wasted man-hours on debate instead of code. But, c'est la vie. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Author tags [was Line width and such minutiae]
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 3:54 PM To: Jakarta Commons Developers List Subject: Re: [all] Author tags [was Line width and such minutiae] Henri Yandell wrote: If we have decided [to remove author tags], then I'm happy to script them all out (and into team list files etc). And we should probably make sure that we take care of disagreements now rather than later. Gary Gregory wrote: Based on the February 18, 2004, Apache Software Foundation Board of Directors Meeting Minutes, author tags are discouraged. AFAIR we haven't ever voted on this, as removing existing author tags is always been a touchy subject when brought up. At present, its a component-level choice. FWIW, we implemented the ASF recommendation in [codec] for the 1.3 release. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Gary Gregory [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Tuesday, March 28, 2006 3:02 PM To: Jakarta Commons Developers List Subject: Re: [all] Line width and such minutiae On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. This sounds to me like a problem with a particular diff tool. I do not think we should restrict our source code based on the limitations of /one/ tool. For those of us using Eclipse, this is not an issue since the tool (Eclipse) presents a nice user-interface that allows me to focus on the nature of the changes as opposed to the changes and the format the changes are given in. We use 120 at work. I think we got the idea from Jakarata Commons but I cannot find a link right now. Plenty of Commons projects use 120, so the number must come from some previous agreement. Perhaps agreement among some subset of us - the components I've worked on use 80 characters. ;-) -- Martin Cooper Gary -- Martin Cooper Hen - 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: [all] Author tags [was Line width and such minutiae]
On 3/28/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: If we have decided [to remove author tags], then I'm happy to script them all out (and into team list files etc). And we should probably make sure that we take care of disagreements now rather than later. Gary Gregory wrote: Based on the February 18, 2004, Apache Software Foundation Board of Directors Meeting Minutes, author tags are discouraged. AFAIR we haven't ever voted on this, as removing existing author tags is always been a touchy subject when brought up. At present, its a component-level choice. I believe that it is general practice in commons to refer to the author in commit comments, and to use the maven team list facility, but I could be wrong. Certainly [collections] still has author tags, although I had recently considered proposing their removal as I now find them a hassle. Sandy McArthur wrote: I have searched some and the arguments don't hold water with me. :-) Many things from lawyers and the board don't make sense ;-) I'm proud of the code I've contributed and I think an @author tag is proper recognition. I suppose that five years ago when I joined, I felt something similar. At that time author tags were allowed, so it wasn't a problem. Over time, that desire for such 'base' recognition has gone. You're probably right eventually. When I'm married and have kids I probably won't even remember this but until then I do care with respect to my own contributions. I think the best policy is to stay true to yourself and be tolerant of people with different policies. In my mind that will work today, tomorrow, and up until the earth is swallowed by the sun. IMHO, the true recognition is from the peers in your community. As a peer, I can say that we have already recognised your contributions so far (by voting you a committer for example). I personally also greatly appreciate the new life that you have instilled in both pool and dbcp. It is a balance though. Martin's 'egoless programming' comment is essentialy correct. I am here because I want to code, I want to learn, because I enjoy the community and I want to share. It is possible that I may benefit career-wise, or perhaps not. What I do know is that I don't feel any need to shout my contribution via an author tag - there are plenty of other outlets to mention the work I do (maven team-list, blog, Javalobby, the server side...) if and when I feel it appropriate. In summary however, I still think a board-level command 'no author tags' was a bit silly as it just created lots of wasted man-hours on debate instead of code. But, c'est la vie. Stephen -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/28/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/28/06, Gary Gregory [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Tuesday, March 28, 2006 3:02 PM To: Jakarta Commons Developers List Subject: Re: [all] Line width and such minutiae On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. This sounds to me like a problem with a particular diff tool. I do not think we should restrict our source code based on the limitations of /one/ tool. For those of us using Eclipse, this is not an issue since the tool (Eclipse) presents a nice user-interface that allows me to focus on the nature of the changes as opposed to the changes and the format the changes are given in. We use 120 at work. I think we got the idea from Jakarata Commons but I cannot find a link right now. Plenty of Commons projects use 120, so the number must come from some previous agreement. Perhaps agreement among some subset of us - the components I've worked on use 80 characters. ;-) The number 80 has numerological properties that imbue the code with a special quality that obviously only you and I appreciate, Martin. Mailers wrapping commit diffs is a sign that we have offended the Gods when we code beyond the end of the card ;-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ah-ha! I *knew* there was a reason! *hurridly reformatting all his code* :-) Phil Steitz wrote: The number 80 has numerological properties that imbue the code with a special quality that obviously only you and I appreciate, Martin. Mailers wrapping commit diffs is a sign that we have offended the Gods when we code beyond the end of the card ;-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEKfECaCoPKRow/gARAgJrAKCgAYTC9m28E3w9wfkqGpOHEVLm1QCfT9GP OVHKMgfZHuC16QRNpO1MFkI= =TOWl -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: snip/ * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. or replace with a mock pool implementation (if possible) This is an interesting idea. Would appreciate suggestions on how exactly to do this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/28/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: snip/ * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. or replace with a mock pool implementation (if possible) This is an interesting idea. Would appreciate suggestions on how exactly to do this. I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Even if you do mock the pool, the test would be testing the behavior of the mock pool as called through Dbcp. I think any interesting interaction with the GOP would be implicitly tested by other unit tests. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Does anyone else think that this should be different? Suggestion: The next version of DBCP should allow you to specify your own implementation in a configuration file. I know that I was looking around for this feature when I first was exploring DBCP and POOL. -Pete
svn commit: r389668 - /jakarta/commons/trunks-proper/
Author: rahul Date: Tue Mar 28 20:25:11 2006 New Revision: 389668 URL: http://svn.apache.org/viewcvs?rev=389668view=rev Log: Removing latka and resources from proper externals Modified: jakarta/commons/trunks-proper/ (props changed) Propchange: jakarta/commons/trunks-proper/ -- --- svn:externals (original) +++ svn:externals Tue Mar 28 20:25:11 2006 @@ -21,7 +21,6 @@ jexl https://svn.apache.org/repos/asf/jakarta/commons/proper/jexl/trunk jxpath https://svn.apache.org/repos/asf/jakarta/commons/proper/jxpath/trunk lang https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk -latka https://svn.apache.org/repos/asf/jakarta/commons/proper/latka/trunk launcher https://svn.apache.org/repos/asf/jakarta/commons/proper/launcher/trunk logging https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk math https://svn.apache.org/repos/asf/jakarta/commons/proper/math/trunk @@ -29,7 +28,6 @@ net https://svn.apache.org/repos/asf/jakarta/commons/proper/net/trunk pool https://svn.apache.org/repos/asf/jakarta/commons/proper/pool/trunk primitives https://svn.apache.org/repos/asf/jakarta/commons/proper/primitives/trunk -resources https://svn.apache.org/repos/asf/jakarta/commons/proper/resources/trunk transaction https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk validator https://svn.apache.org/repos/asf/jakarta/commons/proper/validator/trunk vfs https://svn.apache.org/repos/asf/jakarta/commons/proper/vfs/trunk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389670 - in /jakarta/commons: dormant/latka/ proper/latka/
Author: rahul Date: Tue Mar 28 20:27:00 2006 New Revision: 389670 URL: http://svn.apache.org/viewcvs?rev=389670view=rev Log: Moving latka to dormant Added: jakarta/commons/dormant/latka/ - copied from r389669, jakarta/commons/proper/latka/ Removed: jakarta/commons/proper/latka/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389671 - in /jakarta/commons: dormant/resources/ proper/resources/
Author: rahul Date: Tue Mar 28 20:28:20 2006 New Revision: 389671 URL: http://svn.apache.org/viewcvs?rev=389671view=rev Log: Moving resources to dormant Added: jakarta/commons/dormant/resources/ - copied from r389670, jakarta/commons/proper/resources/ Removed: jakarta/commons/proper/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, Peter Steijn [EMAIL PROTECTED] wrote: I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Does anyone else think that this should be different? Suggestion: The next version of DBCP should allow you to specify your own implementation in a configuration file. I know that I was looking around for this feature when I first was exploring DBCP and POOL. It's been a couple of years since I looked in detail, but IIRC the only place that DBCP locks down the choice of the pool implementation is when you select a specific *implementation* of DataSource (such as org.apache.commons.dbcp.BasicDataSource). If you assemble your own from scratch, you're free to do whatever you want as you build up the stack. Adding plugability inside something like BasicDataSource strikes me as an excellent way to hand a developer a loaded gun, aimed at their foot. The code in a given implementation is going to naturally make assumptions about the underlying pool implementation being used (such as what configuration parameters it accepts) -- if you want a different DBCP implementation, it's really easy to assemble your own. -Pete Craig
svn commit: r389672 - /jakarta/commons/dormant/latka/tags/LATKA_PROPER_03_2006/
Author: rahul Date: Tue Mar 28 20:31:02 2006 New Revision: 389672 URL: http://svn.apache.org/viewcvs?rev=389672view=rev Log: Tagging latka on move from proper Added: jakarta/commons/dormant/latka/tags/LATKA_PROPER_03_2006/ - copied from r389671, jakarta/commons/dormant/latka/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389673 - /jakarta/commons/dormant/resources/tags/RESOURCES_PROPER_03_2006/
Author: rahul Date: Tue Mar 28 20:32:14 2006 New Revision: 389673 URL: http://svn.apache.org/viewcvs?rev=389673view=rev Log: Tagging resources on move from proper Added: jakarta/commons/dormant/resources/tags/RESOURCES_PROPER_03_2006/ - copied from r389672, jakarta/commons/dormant/resources/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389674 - /jakarta/commons/trunks-dormant/
Author: rahul Date: Tue Mar 28 20:36:35 2006 New Revision: 389674 URL: http://svn.apache.org/viewcvs?rev=389674view=rev Log: Adding latka and resources to dormant externals Modified: jakarta/commons/trunks-dormant/ (props changed) Propchange: jakarta/commons/trunks-dormant/ -- --- svn:externals (original) +++ svn:externals Tue Mar 28 20:36:35 2006 @@ -16,11 +16,13 @@ jpath https://svn.apache.org/repos/asf/jakarta/commons/dormant/jpath/trunk jrcs https://svn.apache.org/repos/asf/jakarta/commons/dormant/jrcs/trunk jux https://svn.apache.org/repos/asf/jakarta/commons/dormant/jux/trunk +latka https://svn.apache.org/repos/asf/jakarta/commons/dormant/latka/trunk mapper https://svn.apache.org/repos/asf/jakarta/commons/dormant/mapper/trunk messenger https://svn.apache.org/repos/asf/jakarta/commons/dormant/messenger/trunk pattern https://svn.apache.org/repos/asf/jakarta/commons/dormant/pattern/trunk periodicity https://svn.apache.org/repos/asf/jakarta/commons/dormant/periodicity/trunk reflect https://svn.apache.org/repos/asf/jakarta/commons/dormant/reflect/trunk +resources https://svn.apache.org/repos/asf/jakarta/commons/dormant/resources/trunk rupert https://svn.apache.org/repos/asf/jakarta/commons/dormant/rupert/trunk scaffold https://svn.apache.org/repos/asf/jakarta/commons/dormant/scaffold/trunk services https://svn.apache.org/repos/asf/jakarta/commons/dormant/services/trunk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389676 - /jakarta/commons/dormant/latka/trunk/project.xml
Author: rahul
Date: Tue Mar 28 20:47:03 2006
New Revision: 389676
URL: http://svn.apache.org/viewcvs?rev=389676view=rev
Log:
Adjust repository and site locations after move.
Modified:
jakarta/commons/dormant/latka/trunk/project.xml
Modified: jakarta/commons/dormant/latka/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/dormant/latka/trunk/project.xml?rev=389676r1=389675r2=389676view=diff
==
--- jakarta/commons/dormant/latka/trunk/project.xml (original)
+++ jakarta/commons/dormant/latka/trunk/project.xml Tue Mar 28 20:47:03 2006
@@ -34,7 +34,7 @@
logo/images/logo.png/logo
- urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
+
urlhttp://jakarta.apache.org/commons/sandbox/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
organization
@@ -54,12 +54,12 @@
gumpRepositoryIdjakarta/gumpRepositoryId
issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
-
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
+
siteDirectory/www/jakarta.apache.org/commons/sandbox/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
repository
-
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
-
urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
+
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/dormant/${pom.artifactId.substring(8)}/trunk/connection
+
urlhttp://svn.apache.org/repos/asf/jakarta/commons/dormant/${pom.artifactId.substring(8)}/trunk/url
/repository
mailingLists
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389677 - /jakarta/commons/dormant/resources/trunk/project.xml
Author: rahul
Date: Tue Mar 28 20:48:48 2006
New Revision: 389677
URL: http://svn.apache.org/viewcvs?rev=389677view=rev
Log:
Adjust repository and site locations after move.
Modified:
jakarta/commons/dormant/resources/trunk/project.xml
Modified: jakarta/commons/dormant/resources/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/dormant/resources/trunk/project.xml?rev=389677r1=389676r2=389677view=diff
==
--- jakarta/commons/dormant/resources/trunk/project.xml (original)
+++ jakarta/commons/dormant/resources/trunk/project.xml Tue Mar 28 20:48:48 2006
@@ -28,7 +28,7 @@
description
Resources is a resources component.
/description
- urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
+
urlhttp://jakarta.apache.org/commons/sandbox/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
organization
nameThe Apache Software Foundation/name
@@ -45,10 +45,10 @@
gumpRepositoryIdjakarta/gumpRepositoryId
issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
-
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
+
siteDirectory/www/jakarta.apache.org/commons/sandbox/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
repository
-
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
+
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/dormant/${pom.artifactId.substring(8)}/trunk/connection
urlhttp://svn.apache.org/viewcvs.cgi/url
/repository
mailingLists
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 3/28/06, Peter Steijn [EMAIL PROTECTED] wrote: I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Does anyone else think that this should be different? Suggestion: The next version of DBCP should allow you to specify your own implementation in a configuration file. I know that I was looking around for this feature when I first was exploring DBCP and POOL. It's been a couple of years since I looked in detail, but IIRC the only place that DBCP locks down the choice of the pool implementation is when you select a specific *implementation* of DataSource (such as org.apache.commons.dbcp.BasicDataSource). If you assemble your own from scratch, you're free to do whatever you want as you build up the stack. Adding plugability inside something like BasicDataSource strikes me as an excellent way to hand a developer a loaded gun, aimed at their foot. The code in a given implementation is going to naturally make assumptions about the underlying pool implementation being used (such as what configuration parameters it accepts) -- if you want a different DBCP implementation, it's really easy to assemble your own. Also, my read of some of Dbcp code weeks ago is that if you use a pool with a running idle object (connection) evictor you run the risk of deadlock because of the order of how locks are acquired. synchronization of getting a new connection normally: DbcpConnection - ObjectPool - DbcpConnection.makeObject (implements PoolableObjectFactory) the same object instance on each side of the object pool instance. The idle eviction thread synchronization: ObjectPool - DbcpConnection.activateObject (implements PoolableObjectFactory) Until this is worked out it's not safe to let client code configure their own ObjectPool. Most likely this problem won't turn up in testing under light load but will fall apart in production. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][compress] TAR Filesystem creation temp dir
Hallo! I am running the VFS test suite. I have problems, so I do manual tests. In one of them, I try to parse the following URI (the file does exist) uri = tar:gz://Z:\\programming\\apache\\jakarta\\commons\\vfs\\target\ \test-data\\nested.tar.gz!/nested.tar/file1.txt; byy calling manager.resolveFile(uri); The above url has a problem. Try to change it to som FileObject fifo = VFS.getManager().resolveFile(tar:gz://Z:\\programming\\apache\\jakarta\\commons\\vfs\\target\\test-data\\nested.tar.gz!/nested.tar!/file1.txt); Note the additional ! after nested.tar. You have two layers (tar and gz) so you need two layer demarcations. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389689 - /jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileSystem.java
Author: imario
Date: Tue Mar 28 22:23:53 2006
New Revision: 389689
URL: http://svn.apache.org/viewcvs?rev=389689view=rev
Log:
put back channel only if it is connected
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileSystem.java
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileSystem.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileSystem.java?rev=389689r1=389688r2=389689view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileSystem.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileSystem.java
Tue Mar 28 22:23:53 2006
@@ -142,7 +142,11 @@
{
if (idleChannel == null)
{
-idleChannel = channel;
+ // put back the channel only if it is still connected
+ if (channel.isConnected() !channel.isClosed())
+ {
+ idleChannel = channel;
+ }
}
else
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r389691 - /jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileObject.java
Author: imario
Date: Tue Mar 28 22:29:53 2006
New Revision: 389691
URL: http://svn.apache.org/viewcvs?rev=389691view=rev
Log:
retry sftp stat if it failed
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileObject.java
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileObject.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileObject.java?rev=389691r1=389690r2=389691view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileObject.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/sftp/SftpFileObject.java
Tue Mar 28 22:29:53 2006
@@ -106,22 +106,40 @@
*/
private void statSelf() throws Exception
{
- final ChannelSftp channel = fileSystem.getChannel();
+ ChannelSftp channel = fileSystem.getChannel();
try
{
setStat(channel.stat(relPath));
}
catch (final SftpException e)
{
- // TODO - not strictly true, but jsch 0.1.2 does not
give us
- // enough info in the exception. Should be using:
- // if ( e.id == ChannelSftp.SSH_FX_NO_SUCH_FILE )
- // However, sometimes the exception has the correct id,
and
- // sometimes
- // it does not. Need to look into why.
-
- // Does not exist
- attrs = null;
+ try
+ {
+ // maybe the channel has some problems, so
recreate the channel and retry
+ if (e.id != ChannelSftp.SSH_FX_NO_SUCH_FILE)
+ {
+ channel.disconnect();
+ channel = fileSystem.getChannel();
+ setStat(channel.stat(relPath));
+ }
+ else
+ {
+ // Really does not exist
+ attrs = null;
+ }
+ }
+ catch (final SftpException e2)
+ {
+ // TODO - not strictly true, but jsch 0.1.2
does not give us
+ // enough info in the exception. Should be
using:
+ // if ( e.id == ChannelSftp.SSH_FX_NO_SUCH_FILE
)
+ // However, sometimes the exception has the
correct id, and
+ // sometimes
+ // it does not. Need to look into why.
+
+ // Does not exist
+ attrs = null;
+ }
}
finally
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Line width and such minutiae
Phil Steitz wrote on Wednesday, March 29, 2006 4:27 AM: On 3/28/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/28/06, Gary Gregory [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Tuesday, March 28, 2006 3:02 PM To: Jakarta Commons Developers List Subject: Re: [all] Line width and such minutiae On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. This sounds to me like a problem with a particular diff tool. I do not think we should restrict our source code based on the limitations of /one/ tool. Try to use proportional fonts. Ist arted using it years ago and I will never go back. So linelength gets somewhat pointless :) For those of us using Eclipse, this is not an issue since the tool (Eclipse) presents a nice user-interface that allows me to focus on the nature of the changes as opposed to the changes and the format the changes are given in. We use 120 at work. I think we got the idea from Jakarata Commons but I cannot find a link right now. Plenty of Commons projects use 120, so the number must come from some previous agreement. Perhaps agreement among some subset of us - the components I've worked on use 80 characters. ;-) The number 80 has numerological properties that imbue the code with a special quality that obviously only you and I appreciate, Martin. Mailers wrapping commit diffs is a sign that we have offended the Gods when we code beyond the end of the card ;-) STOP. We must limit the line length to 76. Any longer line will be wrapped by my mailer. :D - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] handling of broken links
Hi! Anybody any ideas of how to resolve this ? I'm guessing that it should either be a FileType.LINK or a regular FileType.FILE and that exists() should return true, but that when accessing the content an exception needs to be thrown. Sometimes I think VFS still do a little bit too much on its own logic. What if we keep the current behaviour but access the filesystem layer even if the file is not existent? (From VFSs point of view). Hmmm ... or your FileType.LINK ... I am not sure. What FS do you use? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Line width and such minutiae
On 3/29/06, Jörg Schaible [EMAIL PROTECTED] wrote: Phil Steitz wrote on Wednesday, March 29, 2006 4:27 AM: On 3/28/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/28/06, Gary Gregory [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Tuesday, March 28, 2006 3:02 PM To: Jakarta Commons Developers List Subject: Re: [all] Line width and such minutiae On 3/28/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: My personal preference is 80 column line widths, partly because this makes diffs readable. Sorry, forgot to add this to the other email. For the record, I like 120 column line widths. Java's a verbose language, 80 feels cramped. People can print in landscape :) For me, printing is not the issue, side-by-side diffs are the issue. I hate having to scroll horizontally all the time to see the actual diffs. That's why I'm with Phil on 80 character widths. This sounds to me like a problem with a particular diff tool. I do not think we should restrict our source code based on the limitations of /one/ tool. Try to use proportional fonts. Ist arted using it years ago and I will never go back. So linelength gets somewhat pointless :) For those of us using Eclipse, this is not an issue since the tool (Eclipse) presents a nice user-interface that allows me to focus on the nature of the changes as opposed to the changes and the format the changes are given in. We use 120 at work. I think we got the idea from Jakarata Commons but I cannot find a link right now. Plenty of Commons projects use 120, so the number must come from some previous agreement. Perhaps agreement among some subset of us - the components I've worked on use 80 characters. ;-) The number 80 has numerological properties that imbue the code with a special quality that obviously only you and I appreciate, Martin. Mailers wrapping commit diffs is a sign that we have offended the Gods when we code beyond the end of the card ;-) STOP. We must limit the line length to 76. Any longer line will be wrapped by my mailer. :D I'd like to formally apologize for any of the times I've been more than the 4th person to respond in a thread. Oops I'm doing it now. :-) A little more seriously though, the svn-to-email script really could use some modernization. We live in an age of mime email and each part of commit message really should be it's own mime part of type text/x-patch or something. (I don't see an existing patch mime-type: http://www.iana.org/assignments/media-types/ ) Part of the problem something that is more structured than text/plain is being labeled as such. This could be a first step to mail clients with built in colorized diff view. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
