svn commit: r493980 - /jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
Author: niallp
Date: Mon Jan 8 00:28:37 2007
New Revision: 493980
URL: http://svn.apache.org/viewvc?view=revrev=493980
Log:
Use LICENSE.txt instead of STATUS.html in file/directory filter tests
(STATUS.html isn't in the source distro created by the ant build)
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java?view=diffrev=493980r1=493979r2=493980
==
---
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
(original)
+++
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
Mon Jan 8 00:28:37 2007
@@ -141,7 +141,7 @@
assertFiltering(filter, new File(imaginary), false);
assertFiltering(filter, new File(imaginary/), false);
-assertFiltering(filter, new File(STATUS.html), false);
+assertFiltering(filter, new File(LICENSE.txt), false);
assertSame(DirectoryFileFilter.DIRECTORY,
DirectoryFileFilter.INSTANCE);
}
@@ -158,7 +158,7 @@
assertFiltering(filter, new File(imaginary), false);
assertFiltering(filter, new File(imaginary/), false);
-assertFiltering(filter, new File(STATUS.html), true);
+assertFiltering(filter, new File(LICENSE.txt), true);
}
public void testPrefix() throws Exception {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 RC1
Fixed: http://svn.apache.org/viewvc?view=revrevision=493980 Niall On 1/8/07, Niall Pemberton [EMAIL PROTECTED] wrote: Everything looks good except the source distro doesn't build - FileFilterTestCase fails because it checks for STATUS.html in testFiles() - but STATUS.html isn't included in the source distro. Niall On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote: I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc1/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Friday (if it makes it that far). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r493981 - /jakarta/commons/proper/io/trunk/project.properties
Author: niallp
Date: Mon Jan 8 00:32:13 2007
New Revision: 493981
URL: http://svn.apache.org/viewvc?view=revrev=493981
Log:
Change the maven build so that the source distro unpacks to a different
directory (as the ant one does)
Modified:
jakarta/commons/proper/io/trunk/project.properties
Modified: jakarta/commons/proper/io/trunk/project.properties
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/project.properties?view=diffrev=493981r1=493980r2=493981
==
--- jakarta/commons/proper/io/trunk/project.properties (original)
+++ jakarta/commons/proper/io/trunk/project.properties Mon Jan 8 00:32:13 2007
@@ -35,6 +35,9 @@
maven.javadoc.source=1.3
maven.javadoc.overview=src/java/org/apache/commons/io/overview.html
+# Make the source distro unzip to a different directory
+maven.dist.src.assembly.dir=${maven.dist.assembly.dir}/src/${maven.final.name}-src
+
maven.checkstyle.properties=checkstyle.xml
maven.jdiff.new.tag=CURRENT
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r493992 - in /jakarta/commons/proper/validator/trunk: maven.xml xdocs/images/
Author: niallp
Date: Mon Jan 8 00:54:39 2007
New Revision: 493992
URL: http://svn.apache.org/viewvc?view=revrev=493992
Log:
Remove duplicate image
Removed:
jakarta/commons/proper/validator/trunk/xdocs/images/
Modified:
jakarta/commons/proper/validator/trunk/maven.xml
Modified: jakarta/commons/proper/validator/trunk/maven.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/maven.xml?view=diffrev=493992r1=493991r2=493992
==
--- jakarta/commons/proper/validator/trunk/maven.xml (original)
+++ jakarta/commons/proper/validator/trunk/maven.xml Mon Jan 8 00:54:39 2007
@@ -48,6 +48,12 @@
/ant:ant
/preGoal
+ preGoal name=site
+copy todir=${maven.build.dir}/docs/images
+ fileset dir=${basedir}/src/site/resources/images/
+/copy
+ /preGoal
+
!-- == --
!-- Copy into the binary distribution --
!-- == --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: On Fri, 5 Jan 2007, Henri Yandell [EMAIL PROTECTED] wrote: As you can see on the list, Matt would like to help out with JXPath. +1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: On Fri, 5 Jan 2007, Henri Yandell [EMAIL PROTECTED] wrote: As you can see on the list, Matt would like to help out with JXPath. +1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494004 - /jakarta/commons/proper/fileupload/trunk/pom.xml
Author: jochen Date: Mon Jan 8 01:57:43 2007 New Revision: 494004 URL: http://svn.apache.org/viewvc?view=revrev=494004 Log: NOTICE.txt and LICENSE.txt are handled by the commons-parent POM, if you activate -Prc or -Prelease. Modified: jakarta/commons/proper/fileupload/trunk/pom.xml Modified: jakarta/commons/proper/fileupload/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diffrev=494004r1=494003r2=494004 == --- jakarta/commons/proper/fileupload/trunk/pom.xml (original) +++ jakarta/commons/proper/fileupload/trunk/pom.xml Mon Jan 8 01:57:43 2007 @@ -22,7 +22,7 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-parent/artifactId -version1/version +version2-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion groupIdcommons-fileupload/groupId @@ -119,16 +119,6 @@ build sourceDirectorysrc/java/sourceDirectory testSourceDirectorysrc/test/testSourceDirectory -resources - resource -directory./directory -targetPathMETA-INF/targetPath -includes - includeNOTICE.txt/include - includeLICENSE.txt/include -/includes - /resource -/resources plugins !-- TODO: remove the following when commons-parent is released - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:svn commit: r493942 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
Hi, Niall, I would beg you to remove the changes you did in http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116823124228193w=2 Reason: A similar section has already been in commons-parent in the past. I have removed this section because of http://jira.codehaus.org/browse/MSOURCES-6 Your resources section triggers this bug and makes it impossible to build a sources jar file with Maven 2. If that fact wasn't clear enough from the comments you removed, then please be so kind to fix them appropriately. It is of course discussable, whether the NOTICE.txt and LICENSE.txt files should always be added to the jar file. If so, I suggest simply moving the invocation of the antrun plugin from the rc and release profiles to the global section. My personal impression is, that most developers would prefer not to loose the time for invoking ant in the usual case. Thanks, Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-247) recognize changes in included Propertiefiles
[ https://issues.apache.org/jira/browse/CONFIGURATION-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462997 ] Mirko Wolf commented on CONFIGURATION-247: -- Dear Oliver, it would be a reasonable solution for me to use the ConfigurationsBuilder, so lets close the request recognize changes in included Propertiefiles Key: CONFIGURATION-247 URL: https://issues.apache.org/jira/browse/CONFIGURATION-247 Project: Commons Configuration Issue Type: New Feature Reporter: Mirko Wolf Properties-Files included in other properties-Files should be recognized by the event-listener / reloading-strategie set on the main properties-File. This is necessary in case of modifications in these included Files. for instance: main.properties include=sample.properties sample.properties [EMAIL PROTECTED] ... when i change the value of mail.address i definitly need a restart of my application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-247) recognize changes in included Propertiefiles
[ https://issues.apache.org/jira/browse/CONFIGURATION-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Wolf resolved CONFIGURATION-247. -- Resolution: Won't Fix See Comments recognize changes in included Propertiefiles Key: CONFIGURATION-247 URL: https://issues.apache.org/jira/browse/CONFIGURATION-247 Project: Commons Configuration Issue Type: New Feature Reporter: Mirko Wolf Properties-Files included in other properties-Files should be recognized by the event-listener / reloading-strategie set on the main properties-File. This is necessary in case of modifications in these included Files. for instance: main.properties include=sample.properties sample.properties [EMAIL PROTECTED] ... when i change the value of mail.address i definitly need a restart of my application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] finder pipeline failed.
Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070108/finder.log http://people.apache.org/~psteitz/commons-nightlies/20070108/pipeline.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-transaction (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-transaction has an issue affecting its community integration. This issue affects 20 projects, and has been outstanding for 3 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-ojb : Commons Jelly - commons-transaction : Commons Identifier Package - commons-vfs : Jakarta commons - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. - ivy : Ivy Core - jakarta-slide : Content Management System based on WebDAV technology - logging-log4j-chainsaw : Chainsaw log viewer - slide-webdavclient : Content Management System based on WebDAV technology - test-ojb : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-transaction/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-transaction-08012007.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-transaction/gump_work/build_jakarta-commons_commons-transaction.html Work Name: build_jakarta-commons_commons-transaction (Type: Build) Work ended in a state of : Failed Elapsed: 3 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 -Dversion=08012007 jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/transaction] 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/logging-log4j/dist/lib/log4j-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-08012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/packages/j2ee_connector-1_5-fr/connector-api.jar:/usr/local/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/tomcat-tc6/output/build/lib/servlet-api.jar - detect: prepare: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/doc [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/doc/apidocs [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/classes [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/lib [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/deploy build: [javac] Compiling 37 source files to /x1/gump/public/workspace/jakarta-commons/transaction/build/classes [javac] [javac] WARNING [javac] [javac] The -source switch defaults to 1.5 in JDK 1.5 and 1.6. [javac] If you specify -target 1.3 you now must also specify -source 1.3. [javac] Ant will implicitly add -source 1.3 for you. Please change your build file. [javac]
[EMAIL PROTECTED]: Project commons-transaction (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-transaction has an issue affecting its community integration. This issue affects 20 projects, and has been outstanding for 3 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-ojb : Commons Jelly - commons-transaction : Commons Identifier Package - commons-vfs : Jakarta commons - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. - ivy : Ivy Core - jakarta-slide : Content Management System based on WebDAV technology - logging-log4j-chainsaw : Chainsaw log viewer - slide-webdavclient : Content Management System based on WebDAV technology - test-ojb : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-transaction/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-transaction-08012007.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-transaction/gump_work/build_jakarta-commons_commons-transaction.html Work Name: build_jakarta-commons_commons-transaction (Type: Build) Work ended in a state of : Failed Elapsed: 3 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 -Dversion=08012007 jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/transaction] 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/logging-log4j/dist/lib/log4j-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-08012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/packages/j2ee_connector-1_5-fr/connector-api.jar:/usr/local/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/tomcat-tc6/output/build/lib/servlet-api.jar - detect: prepare: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/doc [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/doc/apidocs [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/classes [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/lib [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/transaction/build/deploy build: [javac] Compiling 37 source files to /x1/gump/public/workspace/jakarta-commons/transaction/build/classes [javac] [javac] WARNING [javac] [javac] The -source switch defaults to 1.5 in JDK 1.5 and 1.6. [javac] If you specify -target 1.3 you now must also specify -source 1.3. [javac] Ant will implicitly add -source 1.3 for you. Please change your build file. [javac]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 36 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-08012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2308012007, vmgump.apache.org:vmgump-public:2308012007 Gump E-mail Identifier (unique within run) #30. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 36 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-08012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2308012007, vmgump.apache.org:vmgump-public:2308012007 Gump E-mail Identifier (unique within run) #30. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 36 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-08012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2308012007, vmgump.apache.org:vmgump-public:2308012007 Gump E-mail Identifier (unique within run) #40. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 36 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-08012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2308012007, vmgump.apache.org:vmgump-public:2308012007 Gump E-mail Identifier (unique within run) #40. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 10 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: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-08012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[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 10 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: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-08012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 10 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-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/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] 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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-08012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-08012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 10 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-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/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] 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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-08012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-08012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-08012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-08012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
svn commit: r494097 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
Author: niallp
Date: Mon Jan 8 07:46:11 2007
New Revision: 494097
URL: http://svn.apache.org/viewvc?view=revrev=494097
Log:
revert revision 493942 - due to http://jira.codehaus.org/browse/MSOURCES-6
Modified:
jakarta/commons/proper/commons-parent/trunk/pom.xml
Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=494097r1=494096r2=494097
==
--- jakarta/commons/proper/commons-parent/trunk/pom.xml (original)
+++ jakarta/commons/proper/commons-parent/trunk/pom.xml Mon Jan 8 07:46:11 2007
@@ -96,21 +96,6 @@
/mailingList
/mailingLists
build
-resources
- !--
- N.B. If dependant poms specify resources the following entry will
-need to be added as maven only inherits if no resources are
-specified in the dependant pom.
- --
- resource
-directory${basedir}/directory
-targetPathMETA-INF/targetPath
-includes
- includeLICENSE.txt/include
- includeNOTICE.txt/include
-/includes
- /resource
-/resources
plugins
!-- TODO: later use toolchain support to do compilation on an external
JDK 1.3+ compiler --
plugin
@@ -143,6 +128,35 @@
configuration
jdkLevel${maven.compile.source}/jdkLevel
/configuration
+ /plugin
+ plugin
+!-- This should possibly better be done by using a resource
+ definition. However, if we declare a resource with
+ ${basedir} as the base directory, then the
+ maven-source-plugin will add the whole directory to
+ its contents when generating a sources jar.
+
+ see http://jira.codehaus.org/browse/MSOURCES-6
+--
+artifactIdmaven-antrun-plugin/artifactId
+executions
+ execution
+phasegenerate-resources/phase
+configuration
+ tasks
+copy todir=${project.build.outputDirectory}/META-INF
+ fileset dir=${basedir}
+include name=LICENSE.txt /
+include name=NOTICE.txt /
+ /fileset
+/copy
+ /tasks
+/configuration
+goals
+ goalrun/goal
+/goals
+ /execution
+/executions
/plugin
/plugins
/build
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r493942 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
On 1/8/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, Niall, I would beg you to remove the changes you did in http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116823124228193w=2 Reason: A similar section has already been in commons-parent in the past. I have removed this section because of http://jira.codehaus.org/browse/MSOURCES-6 Your resources section triggers this bug and makes it impossible to build a sources jar file with Maven 2. If that fact wasn't clear enough from the comments you removed, then please be so kind to fix them appropriately. Apologies, I mis-read/understood the comment and didn't think it was still an issue reverted: http://svn.apache.org/viewvc?view=revrevision=494097 Niall It is of course discussable, whether the NOTICE.txt and LICENSE.txt files should always be added to the jar file. If so, I suggest simply moving the invocation of the antrun plugin from the rc and release profiles to the global section. My personal impression is, that most developers would prefer not to loose the time for invoking ant in the usual case. Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494100 - /jakarta/commons/proper/validator/trunk/pom.xml
Author: niallp
Date: Mon Jan 8 07:50:22 2007
New Revision: 494100
URL: http://svn.apache.org/viewvc?view=revrev=494100
Log:
remove resource element due to http://jira.codehaus.org/browse/MSOURCES-6
Modified:
jakarta/commons/proper/validator/trunk/pom.xml
Modified: jakarta/commons/proper/validator/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/pom.xml?view=diffrev=494100r1=494099r2=494100
==
--- jakarta/commons/proper/validator/trunk/pom.xml (original)
+++ jakarta/commons/proper/validator/trunk/pom.xml Mon Jan 8 07:50:22 2007
@@ -112,14 +112,6 @@
build
resources
resource
-directory${basedir}/directory
-targetPathMETA-INF/targetPath
-includes
-includeLICENSE.txt/include
-includeNOTICE.txt/include
-/includes
-/resource
-resource
directorysrc/main/resources/directory
/resource
resource
@@ -156,6 +148,7 @@
descriptors
descriptorsrc/main/assembly/bin.xml/descriptor
descriptorsrc/main/assembly/src.xml/descriptor
+descriptorsrc/main/assembly/sources.xml/descriptor
/descriptors
tarLongFileModegnu/tarLongFileMode
/configuration
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494102 - /jakarta/commons/proper/validator/trunk/pom.xml
Author: niallp Date: Mon Jan 8 07:52:23 2007 New Revision: 494102 URL: http://svn.apache.org/viewvc?view=revrev=494102 Log: oops - changed by mistake Modified: jakarta/commons/proper/validator/trunk/pom.xml Modified: jakarta/commons/proper/validator/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/pom.xml?view=diffrev=494102r1=494101r2=494102 == --- jakarta/commons/proper/validator/trunk/pom.xml (original) +++ jakarta/commons/proper/validator/trunk/pom.xml Mon Jan 8 07:52:23 2007 @@ -148,7 +148,6 @@ descriptors descriptorsrc/main/assembly/bin.xml/descriptor descriptorsrc/main/assembly/src.xml/descriptor -descriptorsrc/main/assembly/sources.xml/descriptor /descriptors tarLongFileModegnu/tarLongFileMode /configuration - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons id package code issue
Hi all, I am trying to downloadthe commons id package found at http://jakarta.apache.org/commons/sandbox/id/ , and write java program for generating UUID's , but how do I get the code ? jar , zip ? It takes me to a folders page , I guess I need to download from a repository ? , can some body point me in the right direction. Sorry for sending personal mail, I tried sending it to the groups , but not sure it went through. Thanks Pradeep
svn commit: r494111 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
Author: niallp Date: Mon Jan 8 08:23:48 2007 New Revision: 494111 URL: http://svn.apache.org/viewvc?view=revrev=494111 Log: Specify maven-jar-plugin version 2.1 Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=494111r1=494110r2=494111 == --- jakarta/commons/proper/commons-parent/trunk/pom.xml (original) +++ jakarta/commons/proper/commons-parent/trunk/pom.xml Mon Jan 8 08:23:48 2007 @@ -96,6 +96,15 @@ /mailingList /mailingLists build +pluginManagement + plugins +plugin + groupIdorg.apache.maven.plugins/groupId + artifactIdmaven-jar-plugin/artifactId + version2.1/version +/plugin + /plugins +/pluginManagement plugins !-- TODO: later use toolchain support to do compilation on an external JDK 1.3+ compiler -- plugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] betwixt finder failed.
On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070107/betwixt.log http://people.apache.org/~psteitz/commons-nightlies/20070107/finder.log The Maven 2 installation running the nightly builds needs to upgrade its jar-plugin to version 2.1, otherwise Phil's changes to the parent pom will cause this failure for finder or other M2 builds. What is the best way to do that? Wouldn't it be best to put the explicit versioned dependency in the pom(s) that need it? I don't like having builds depend on local setups. I guess if its maven itself that needs to be upgraded we can doc that somewhere and do it, but if its a plugin, we learned the hard way with m1 that its best to specify these in the poms. Yes I've thought about this some more and I agree that the best thing would be to lock down the versions in a parent pom somewhere, preferably commons-parent. That way we will have reproducible builds no matter runs it. Also, what changes to the parent are you talking about? That was me rather than Phil :-( http://svn.apache.org/viewvc?view=revrevision=493671 Maven-jar-plugin stopped adding Implementation-* and Specification-* stuff in the manifest by default starting with version 2.1. You're probably using that new version locally and have not noticed anything. The log says there is a duplicate Implementation-Title. I've added 2.1 to the parent pom http://svn.apache.org/viewvc?view=revrevision=494111 Niall Thanks for looking into this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of Net/FrequentlyAskedQuestions by dgsoft
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki
for change notification.
The following page has been changed by dgsoft:
http://wiki.apache.org/jakarta-commons/Net/FrequentlyAskedQuestions
The comment on the change is:
old code always transfers the whole buffer even if less bytes are read
--
InputStream fis = new FileInputStream(c:\\temp\\B.pdf);
OutputStream os = client.storeFileStream(B.pdf);
- byte buf[] = new byte[8192];
+ byte buf[] = new byte[8192];
- while (fis.read(buf) != -1) {
- os.write(buf);
- }
+ int bytesRead = fis.read(buf);
+ while (bytesRead != -1) {
+ os.write(buf, 0, bytesRead);
+ bytesRead = fis.read(buf);
+ }
fis.close();
os.close();
client.completePendingCommand();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-69) JXPath doesn't properly search for XBeanInfo defined for a parent class.
[
https://issues.apache.org/jira/browse/JXPATH-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463073
]
Matt Benson commented on JXPATH-69:
---
It'd be helpful if you could attach concrete examples of what you're doing.
Thanks!
JXPath doesn't properly search for XBeanInfo defined for a parent class.
Key: JXPATH-69
URL: https://issues.apache.org/jira/browse/JXPATH-69
Project: Commons JXPath
Issue Type: Bug
Environment: java 1.5, WinXP
Reporter: dror
class A { ... }
class B extends A { ... }
class AXBeanInfo implmements JXPathBeanInfo { ... }
Now if I try to
JXPathContext.newContext( new B() )
it will fail to read the XBeanInfo of the base class (A), and will use
simplebeaninfo instead.
if instead I first do
JXPathContext.newContext( new A() )
and then do the
JXPathContext.newContext( new B() )
it will work.
(it will probably work if A implemented the JXPathBeanInfo interface by
itself, but I don't want it to require that. my current workarround is to do
the above dummy context initialization)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
Niall Pemberton wrote: Hi Denis, Good job on the skin - I added an m2 build to Validator using it and looks great to me - I've published the m2 generated site for Validator here: http://people.apache.org/~niallp/validator-m2/ I can't see any problems with the skin - but noticed the following site issues which look like maven plugin features/bugs: 1) Maven changes absolute URLs specified in site.xml to relative URLs. This isn't a problem for the web sites - but components (like validator) that include them as docs in the distro it means that the breadcrumbs (Jakarta and Commons) and links to previous versions JavaDocs that are only on the site no longer work. Yep, the links will work once the site is published, but it should work for a staged site as well. This is a known issue: http://jira.codehaus.org/browse/MSITE-159 2) The changes report doesn't seem to like content that contains markup - it seems to split out the markup into a separate report - m1 and m2(x2) changes reports are here for comparison: http://jakarta.apache.org/commons/validator/changes-report.html http://people.apache.org/~niallp/validator-m2/changes-report.html (markup removed) I'll take a closer look at this. Unfortunately the M2 plugin is not yet up to par with its M1 counterpart. http://people.apache.org/~niallp/validator-m2/changes.html (removed markup) I noticed this file too. We need to exclude this file from the M2 site build. I'll patch a parent pom shortly. 3) Validator has a custom issue-tracking page - which seems to cause the site plugin to omit it from the project information menu and page: http://people.apache.org/~niallp/validator-m2/project-info.html If I delete the custom version - then m2 generates one and includes it on both the above. Strange, I'll look into it. more comments inline below... On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Here's a status report on how far I have gotten. The sandbox parent is finished. I have added a bunch of reports to it that seems logical, at least to me, for all components. These are: - Cobertura (test coverage) - Javadoc - JXR (cross reference for sources) - PMD - Surefire (test results) - JDepend (metrics) - Taglist (list things left to do) One thing I noticed recently with Cobertura is that it includes some JavaScript files with various (GPL+ other) licenses - maybe we should switch to JCoverage instead: http://tinyurl.com/ynbjge I hadn't noticed that. I'll take it up over in Maven land. The individual components have at least the reports they have in their M1 sites, with these exceptions: Sounds like a good plan - how will this be handled for proper components - is commons-parent the right place to put them or do we need a proper-parent pom? Once we settle on a standard set my plan is to move them to the parent pom. I don't currently see the need for a proper pom. - i18n is missing JCoverage, but Cobertura does the same thing - Id and Proxy are missing Clover, but Cobertura does the same thing - All are missing JavaDoc Report, JavaDoc Warnings Report and Link check, which does not exist in M2 - All are missing Project License which is available in another place in M2 Some components have their own reports as well. These didn't seem like something suitable for all components. These reports are: - Checkstyle (5 component) (requires a configuration file) - Changelog (3 component) - Changes (1 component) (requires a changes.xml file) - FindBugs (1 component) Still to do: - I haven't been able to get the logo in the upper right corner to work simultaneously for M1 and M2. This affects I18n, Id and Proxy. I fixed this in Validator by copying the logo to site/resources/images and including a bannerRight element in site.xml Yes, that's the easy way to go. I was hoping that I wouldn't need to resort to copying stuff in SVN. Some components have the Gimp or Photoshop source file in SVN as well. These need to go somewhere too. - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. - Id has a downloads page that refers to an M1 report. Need to decide how to deal with that. Can't have M1 and M2 working at the same time for this one. I assume you mean cvs-usage.html? While id is in the sandbox we could copy the cvs-usage.html to source-repository.html in the maven.xml and refer to source-repository.html on the downloads page. Yes, that's the file I meant. I think we'll just keep it like is for now. When the M2 site build is finished, we change the page to refer to the appropriate M2 page. We shouldn't need the M1 site build once we've switched to M1. Once its out of the sandbox I would remove the downloads page altogether and replace it with the standard downloads_commons-id.cgi True. Alternatively just delete the downloads page now. Thanks again for doing all this Niall - Publish staged sites
Re: [nightly build] betwixt finder failed.
Niall Pemberton wrote: On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070107/betwixt.log http://people.apache.org/~psteitz/commons-nightlies/20070107/finder.log The Maven 2 installation running the nightly builds needs to upgrade its jar-plugin to version 2.1, otherwise Phil's changes to the parent pom will cause this failure for finder or other M2 builds. What is the best way to do that? Wouldn't it be best to put the explicit versioned dependency in the pom(s) that need it? I don't like having builds depend on local setups. I guess if its maven itself that needs to be upgraded we can doc that somewhere and do it, but if its a plugin, we learned the hard way with m1 that its best to specify these in the poms. Yes I've thought about this some more and I agree that the best thing would be to lock down the versions in a parent pom somewhere, preferably commons-parent. That way we will have reproducible builds no matter runs it. Also, what changes to the parent are you talking about? That was me rather than Phil :-( http://svn.apache.org/viewvc?view=revrevision=493671 Sorry Phil! Maven-jar-plugin stopped adding Implementation-* and Specification-* stuff in the manifest by default starting with version 2.1. You're probably using that new version locally and have not noticed anything. The log says there is a duplicate Implementation-Title. I've added 2.1 to the parent pom http://svn.apache.org/viewvc?view=revrevision=494111 Great, thanks. Niall Thanks for looking into this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
Hi Dennis, Dennis Lundberg wrote: [snip] - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. I tried to look at this, but where's the commons-sandbox parent pom? % [EMAIL PROTECTED] ~/src/Jakarta/sandbox/id $ mvn test [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.commons ArtifactId: commons-sandbox Version: 1-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.commons:commons-sandbox:pom:1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [snip] % and % [EMAIL PROTECTED] ~/src/Jakarta/sandbox/id $ svn list https://svn.apache.org/repos/asf/jakarta/commons/sandbox commons-skin/ compress/ csv/ exec/ finder/ i18n/ id/ javaflow/ jci/ js2j/ openpgp/ pipeline/ project-template/ proposal/ proxy/ % There's no sandpox-parent project and neither proposal nor project-template seems to contain the parent ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons id package code issue
Hi Pradeep, Pradeep Arumalla wrote: Hi all, I am trying to downloadthe commons id package found at http://jakarta.apache.org/commons/sandbox/id/ , and write java program for generating UUID's , but how do I get the code ? jar , zip ? It takes me to a folders page , I guess I need to download from a repository ? , can some body point me in the right direction. Sorry for sending personal mail, I tried sending it to the groups , but not sure it went through. there has been no release yet, but you may also download from the nightly snapshots: http://people.apache.org/builds/jakarta-commons/nightly/commons-id/ Yes, we're aware, that we need to update the site ... it will happen as soon as the jakarta commons build with M2. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
On 1/8/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Dennis, Dennis Lundberg wrote: [snip] - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. I tried to look at this, but where's the commons-sandbox parent pom? snip/ In trunks-sandbox, more specifically: https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/pom.xml -Rahul % [EMAIL PROTECTED] ~/src/Jakarta/sandbox/id $ mvn test [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.commons ArtifactId: commons-sandbox Version: 1-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.commons:commons-sandbox:pom:1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [snip] % and % [EMAIL PROTECTED] ~/src/Jakarta/sandbox/id $ svn list https://svn.apache.org/repos/asf/jakarta/commons/sandbox commons-skin/ compress/ csv/ exec/ finder/ i18n/ id/ javaflow/ jci/ js2j/ openpgp/ pipeline/ project-template/ proposal/ proxy/ % There's no sandpox-parent project and neither proposal nor project-template seems to contain the parent ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494179 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
Author: dennisl Date: Mon Jan 8 11:47:11 2007 New Revision: 494179 URL: http://svn.apache.org/viewvc?view=revrev=494179 Log: Exclude the changes file that is used by the changes-plugin, as it interferes with the site generation. Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=494179r1=494178r2=494179 == --- jakarta/commons/proper/commons-parent/trunk/pom.xml (original) +++ jakarta/commons/proper/commons-parent/trunk/pom.xml Mon Jan 8 11:47:11 2007 @@ -176,10 +176,11 @@ groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId configuration - !-- Exclude the navigation file for Maven 1 sites, as it interferes - with the site generation. -- + !-- Exclude the navigation file for Maven 1 sites + and the changes file used by the changes-plugin, + as they interfere with the site generation. -- moduleExcludes -xdocnavigation.xml/xdoc +xdocnavigation.xml,changes.xml/xdoc /moduleExcludes /configuration /plugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Statistics for ftp
Do you know if there's a command line version for the statistics page shown in the ftpd_ui? I'd like to get statistics for an always running ftp server without having to open the gui or restart the ftp server. Ideally, I'd like to view stats in a web page. Thanks, Susanne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r493942 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
On 1/8/07, Niall Pemberton [EMAIL PROTECTED] wrote: reverted: http://svn.apache.org/viewvc?view=revrevision=494097 Thank you! -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 RC1
-1, here's why... After reviewing the javadoc, I realised that having an inner class as an exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong in code. I propose that this exception is promoted to a top level class, and renamed to DirectoryWalkCancelledException. Since we need to build a new RC for Niall's fix, this shouldn't be a big problem if people agree. If people disagree with my analysis, then I will of course re-evaluate this -1 (for which I apologise...) Stephen Henri Yandell wrote: I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc1/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Friday (if it makes it that far). 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]
[jira] Updated: (CONFIGURATION-78) [configuration] Inconsistent handling for keys that don't exist
[ https://issues.apache.org/jira/browse/CONFIGURATION-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-78: -- Fix Version/s: 2.0 Because such a change would affect existing code it should be made only in a major release. [configuration] Inconsistent handling for keys that don't exist --- Key: CONFIGURATION-78 URL: https://issues.apache.org/jira/browse/CONFIGURATION-78 Project: Commons Configuration Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Ittay Dror Fix For: 2.0 The getXXX(String key) methods in AbstractConfiguration are not consistent in how they handle non-existing keys: getProperty(String key) - returns null getString(String key) - throws an exception if isThrowExceptionOnMissing is true getShort(String key) - throws an exception getStringArray(String key) - returns an empty array (why not null?) etc. I suggest that all these methods (include getProperty()) will check isThrowExceptionOnMissing and if true, throw an exception. As it is, it makes it hard to extend this class, and use Configuration in general. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SANDBOX-26) [jci] Eclipse compiler breaks if packages have capital letters
[
https://issues.apache.org/jira/browse/SANDBOX-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463126
]
Justine Blackmore Hlista commented on SANDBOX-26:
-
This problem gets exposed when using JBoss Rules and loading/compiling rules at
runtime that use classes from packages that have caps. We can't depend on
convention since our clients will (hopefully) be writing the business objects
and business rules and may have funny notions about package names.
[jci] Eclipse compiler breaks if packages have capital letters
--
Key: SANDBOX-26
URL: https://issues.apache.org/jira/browse/SANDBOX-26
Project: Commons Sandbox
Issue Type: Bug
Components: JCI
Environment: Operating System: other
Platform: Other
Reporter: Mark Proctor
Assigned To: Torsten Curdt
Although convention says we shouldn't put capitals in package names, this is
not
something that is enforced by the JVM and some users may do this. I don't
think
it should be jci enforcing that naming convention.
See line 229 of EclipseJavaCompiler.
if (Character.isUpperCase(packageName[0])) {
return false;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-26) [configuration] Consider returning a concatenation of the list properties with getString()
[ https://issues.apache.org/jira/browse/CONFIGURATION-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-26: -- Fix Version/s: 2.0 Setting fix version to the next major release because this will probably involve an API change. [configuration] Consider returning a concatenation of the list properties with getString() -- Key: CONFIGURATION-26 URL: https://issues.apache.org/jira/browse/CONFIGURATION-26 Project: Commons Configuration Issue Type: Bug Environment: Operating System: All Platform: All Reporter: Ittay Dror Fix For: 2.0 in AbstractConfiguration.resolveContainerStore (javadoc): * Returns an object from the store described by the key. If the value is a * List object, replace it with the first object in the list. but what if getProperty returns a List because this is the type of the property? this code will silently grab the first elemen. I don't understand why. Probably the reason is that some class extending AbstractConfiguration returns List for properties. In this case I think the better approach is to have that class return the first element instead, rather than returning the List and letting AbstractConfiguration (which is used by many other implementations, including outside of the configuration package) handle it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494198 - /jakarta/commons/proper/validator/trunk/pom.xml
Author: dennisl Date: Mon Jan 8 13:20:49 2007 New Revision: 494198 URL: http://svn.apache.org/viewvc?view=revrev=494198 Log: Remove configuration for maven-site-plugin that is available in the parent. Modified: jakarta/commons/proper/validator/trunk/pom.xml Modified: jakarta/commons/proper/validator/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/pom.xml?view=diffrev=494198r1=494197r2=494198 == --- jakarta/commons/proper/validator/trunk/pom.xml (original) +++ jakarta/commons/proper/validator/trunk/pom.xml Mon Jan 8 13:20:49 2007 @@ -226,16 +226,6 @@ plugin groupIdorg.apache.maven.plugins/groupId -artifactIdmaven-site-plugin/artifactId -configuration -moduleExcludes -xdoc**/navigation.xml/xdoc -/moduleExcludes -/configuration -/plugin - -plugin -groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId /plugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
Simon Kitching skitching at apache.org writes: When using maven, only the first run needs to download the jars ... So, no need for internet access at build time. For ant ... This can be run *once* to download the jars, but is not part of the main build task, so there is no need for internet access at build time. Even if only for the first run you need a build environment for downloading the dependencies. That's the point. (I speak from experience. In my company ...) A poor corporate internet access policy at one company is *NOT* a good justification for misusing the Apache SVN repository. 1. How can be a misuse what was (inevitably?) custom for years? I don't know how Jakarta Commons handled this before Maven. Of course SVN might not be perfect for it. But as long as infrastructure team does not even discourage from committing jars I don't see a real problem with it. And for commons transaction we talk about other magnitudes than for Cocoon (665 KB vs. 40-45 MB). 2. I don't give justifications for enacting a law or something like that. I only gave an argument which might be considered as well. Other examples might be imaginable. If it is common understanding to do it the other way, be it for unification or other reasons mentioned, I'm ok with it. Thanks for your understanding. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TRANSACTION-11) Improve relationship between ResourceManager and FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated TRANSACTION-11: - Fix Version/s: 1.2 Assignee: Jörg Heinicke (was: Oliver Zeigermann) Affects Version/s: (was: 1.2) Improve relationship between ResourceManager and FileResourceManager Key: TRANSACTION-11 URL: https://issues.apache.org/jira/browse/TRANSACTION-11 Project: Commons Transaction Issue Type: Improvement Affects Versions: 1.1 Reporter: Jeremy Fujimoto-Johnson Assigned To: Jörg Heinicke Fix For: 1.2 Attachments: commons-transaction-rm-patch.txt Add the reset method to ResourceManager so that classes using a ResourceManager won't have to cast it to FileResourceManager to call this method. Add new constructors to FileResourceManager so that it can be constructed with the default timeout period for transactions already specified so that you don't have to cast to FileResourceManager to set it later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Author: joerg Date: Mon Jan 8 13:41:21 2007 New Revision: 494203 URL: http://svn.apache.org/viewvc?view=revrev=494203 Log: TRANSACTION-11: Added setDefaultTransactionTimeout() and reset() to ResourceManager. Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?view=diffrev=494203r1=494202r2=494203 == --- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Mon Jan 8 13:41:21 2007 @@ -29,6 +29,7 @@ - Added functions to FileResourceManager for copying and moving resources. - Added possibility to append to (instead of overwriting) an existing resource with writeResource in FileResourceManager. - Added LoggerFacade implementation for Jakarta Commons Logging +- Added setDefaultTransactionTimeout() and reset() to ResourceManager (Jira issue TRANSACTION-11). BUGFIXES FROM 1.1 - Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java?view=diffrev=494203r1=494202r2=494203 == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Mon Jan 8 13:41:21 2007 @@ -133,6 +133,13 @@ public boolean recover() throws ResourceManagerSystemException; /** + * Resets the store if applicable (optional operation). + * + * @throws UnsupportedOperationException if the codereset/code operation is not supported by this ResourceManager. + */ +public void reset(); + +/** * Gets the default isolation level as an integer. * The higher the value the higher the isolation. * @@ -193,17 +200,27 @@ public void setIsolationLevel(Object txId, int level) throws ResourceManagerException; /** - * Gets the default transaction timeout. After this time expires and the concerned transaction - * has not finished - either rolled back or committed - the resource manager is allowed and - * also encouraged - but not required - to abort the transaction and to roll it back. + * Gets the default transaction timeout in milliseconds. + * After this time expires and the concerned transaction has not finished + * - either rolled back or committed - the resource manager is allowed and + * also encouraged - but not required - to abort the transaction and to roll it back. * - * @return default transaction timeout + * @return default transaction timeout in milliseconds * @throws ResourceManagerException if an error occured */ public long getDefaultTransactionTimeout() throws ResourceManagerException; /** - * Gets the transaction timeout of the specified transaction. + * Sets the default transaction timeout in milliseconds. + * + * @param mSecs default transaction timeout in milliseconds + * @throws ResourceManagerException if an error occured + * @see #getDefaultTransactionTimeout + */ +public void setDefaultTransactionTimeout(long mSecs) throws ResourceManagerException; + +/** + * Gets the transaction timeout of the specified transaction in milliseconds. * * @param txId identifier for the concerned transaction * @return transaction timeout of the specified transaction in milliseconds @@ -213,7 +230,7 @@ public long getTransactionTimeout(Object txId) throws ResourceManagerException; /** - * Sets the transaction timeout of the specified transaction. + * Sets the transaction timeout of the specified transaction in milliseconds. * * @param txId identifier for the concerned transaction * @param mSecs transaction timeout of the specified transaction in milliseconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TRANSACTION-11) Improve relationship between ResourceManager and FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke resolved TRANSACTION-11. -- Resolution: Fixed Added both reset() and setDefaultTransactionTimeout(). reset(): It's better to extend the interface than forcing to cast to class. setDefaultTransactionTimeout(): It will be needed for JTA/JCA as well as it does not know transaction specific timeout. It's also only consistent with getDefaultTransactionTimeout() already existing. Both changes should have nearly no effect as FileResourceManager already implements those functions. If there are other implementations of ResourceManager out there, those both functions are trivial to implement. Improve relationship between ResourceManager and FileResourceManager Key: TRANSACTION-11 URL: https://issues.apache.org/jira/browse/TRANSACTION-11 Project: Commons Transaction Issue Type: Improvement Affects Versions: 1.1 Reporter: Jeremy Fujimoto-Johnson Assigned To: Jörg Heinicke Fix For: 1.2 Attachments: commons-transaction-rm-patch.txt Add the reset method to ResourceManager so that classes using a ResourceManager won't have to cast it to FileResourceManager to call this method. Add new constructors to FileResourceManager so that it can be constructed with the default timeout period for transactions already specified so that you don't have to cast to FileResourceManager to set it later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TRANSACTION-13) JTA Compliant
[ https://issues.apache.org/jira/browse/TRANSACTION-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated TRANSACTION-13: - Fix Version/s: 1.3 JTA Compliant - Key: TRANSACTION-13 URL: https://issues.apache.org/jira/browse/TRANSACTION-13 Project: Commons Transaction Issue Type: New Feature Reporter: Cyrille Assigned To: Jörg Heinicke Fix For: 1.3 Is there a plan to make Commons-Transaction compliant with JTA (Java Transaction API) ? It would be great to get it. For exemple, in case of a web file upload, we could make one transaction for tose 2 operations : 1) writing metadata in database (title,description...), 2) writing the file on the filesystem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
On 1/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: joerg Date: Mon Jan 8 13:41:21 2007 New Revision: 494203 URL: http://svn.apache.org/viewvc?view=revrev=494203 snip/ This change warrants a major release for [transaction]. -Rahul Log: TRANSACTION-11: Added setDefaultTransactionTimeout() and reset() to ResourceManager. Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?view=diffrev=494203r1=494202r2=494203 == --- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Mon Jan 8 13:41:21 2007 @@ -29,6 +29,7 @@ - Added functions to FileResourceManager for copying and moving resources. - Added possibility to append to (instead of overwriting) an existing resource with writeResource in FileResourceManager. - Added LoggerFacade implementation for Jakarta Commons Logging +- Added setDefaultTransactionTimeout() and reset() to ResourceManager (Jira issue TRANSACTION-11). BUGFIXES FROM 1.1 - Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java?view=diffrev=494203r1=494202r2=494203 == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Mon Jan 8 13:41:21 2007 @@ -133,6 +133,13 @@ public boolean recover() throws ResourceManagerSystemException; /** + * Resets the store if applicable (optional operation). + * + * @throws UnsupportedOperationException if the codereset/code operation is not supported by this ResourceManager. + */ +public void reset(); + +/** * Gets the default isolation level as an integer. * The higher the value the higher the isolation. * @@ -193,17 +200,27 @@ public void setIsolationLevel(Object txId, int level) throws ResourceManagerException; /** - * Gets the default transaction timeout. After this time expires and the concerned transaction - * has not finished - either rolled back or committed - the resource manager is allowed and - * also encouraged - but not required - to abort the transaction and to roll it back. + * Gets the default transaction timeout in milliseconds. + * After this time expires and the concerned transaction has not finished + * - either rolled back or committed - the resource manager is allowed and + * also encouraged - but not required - to abort the transaction and to roll it back. * - * @return default transaction timeout + * @return default transaction timeout in milliseconds * @throws ResourceManagerException if an error occured */ public long getDefaultTransactionTimeout() throws ResourceManagerException; /** - * Gets the transaction timeout of the specified transaction. + * Sets the default transaction timeout in milliseconds. + * + * @param mSecs default transaction timeout in milliseconds + * @throws ResourceManagerException if an error occured + * @see #getDefaultTransactionTimeout + */ +public void setDefaultTransactionTimeout(long mSecs) throws ResourceManagerException; + +/** + * Gets the transaction timeout of the specified transaction in milliseconds. * * @param txId identifier for the concerned transaction * @return transaction timeout of the specified transaction in milliseconds @@ -213,7 +230,7 @@ public long getTransactionTimeout(Object txId) throws ResourceManagerException; /** - * Sets the transaction timeout of the specified transaction. + * Sets the transaction timeout of the specified transaction in milliseconds. * * @param txId identifier for the concerned transaction * @param mSecs transaction timeout of the specified transaction in milliseconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TRANSACTION-14) Separate transaction handling from resource handling (split ResourceManager interface)
Separate transaction handling from resource handling (split ResourceManager interface) -- Key: TRANSACTION-14 URL: https://issues.apache.org/jira/browse/TRANSACTION-14 Project: Commons Transaction Issue Type: Improvement Reporter: Jörg Heinicke Fix For: 2.0 http://marc.theaimsgroup.com/?t=11528064431r=1w=4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
On Jan 7, 2007, at 6:28 PM, Phil Steitz wrote: I see the geronimo spec jars were added with the comment that they had been recompiled for JDK 1.3. If that is necessary, its probably better to first ask geronimo to produce *different* artifacts that satisfy this, or at least to rename these reccompiled artifacts. /me ears perk up If someone needs JDK 1.3 versions of any spec jar, I'd be happy to help. OpenJPA had a similar request recently (JDK 1.3 version of JTA 1.1) and I made sure to do the final release of that spec with JDK 1.3. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TRANSACTION-12) Use NIO for file copying/moving
[ https://issues.apache.org/jira/browse/TRANSACTION-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated TRANSACTION-12: - Fix Version/s: 2.0 For the moment I'd postpone this one after a possible refactoring. But if you provide a more or less backwards compatible way it can go into an earlier release as well ;) Use NIO for file copying/moving --- Key: TRANSACTION-12 URL: https://issues.apache.org/jira/browse/TRANSACTION-12 Project: Commons Transaction Issue Type: Wish Affects Versions: 1.2 Reporter: Holger Hoffstätte Fix For: 2.0 Attachments: moveByRenameAndNIO.txt The Mule project (http://mule.codehaus.org/) is considering adoption of commons-transaction for (among other things) file transactions. Unfortunately inspection of the code reveals that FileHelper copies files in the slowest possible way (traditional Java I/O via Input/OutputStreams). Since some of our users move lots and/or large files (hundreds of megabytes to gigabytes) we implemented file moving by rename (atomic and obviously very fast when source and target are on the same filesystem) and NIO as backup strategy (a lot less CPU usage). Attached is a code snippet that outlines the procedure; it would be cool if c-tx could adopt a similar strategy for moving via rename-first and copy via NIO. I do not know if and how this might conflict with c-tx's transactional behaviour and recovery but then again it is just a suggestion. :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
On 1/8/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Simon Kitching skitching at apache.org writes: When using maven, only the first run needs to download the jars ... So, no need for internet access at build time. For ant ... This can be run *once* to download the jars, but is not part of the main build task, so there is no need for internet access at build time. Even if only for the first run you need a build environment for downloading the dependencies. That's the point. (I speak from experience. In my company ...) A poor corporate internet access policy at one company is *NOT* a good justification for misusing the Apache SVN repository. 1. How can be a misuse what was (inevitably?) custom for years? I don't know how Jakarta Commons handled this before Maven. Of course SVN might not be perfect for it. But as long as infrastructure team does not even discourage from committing jars I don't see a real problem with it. And for commons transaction we talk about other magnitudes than for Cocoon (665 KB vs. 40-45 MB). 2. I don't give justifications for enacting a law or something like that. I only gave an argument which might be considered as well. Other examples might be imaginable. If it is common understanding to do it the other way, be it for unification or other reasons mentioned, I'm ok with it. The problem here is not disk space or overhead on the SCM server (although you won't hurt my feelings if you take actions that make the Apache Subversion server run faster :-). The problem is one of engineering best practices. Storing JAR files in your source repository (or pretty much any other scenario where you check in things that have been generated, instead of rebuilding them) has the following negative impacts: * Bypasses the normal mechanisms people use to verify that the bits they are depending on have not been corrupted (either accidentally or maliciously). A cautious downstream user will go directly to the origin for every package they depend on, and validate checksums and signatures. You are asking your downstream users to trust *you* to not have messed with these jar files. * Typically leads to a build environment where *only* the copy of the dependent jars in your repository are used. That makes life much harder for downstream users who might have several packages that need the same dependency, and need to be sure that their entire application * Creates redundant copies of shared dependencies in the build environment of your downstream users (if they use lots of packages that follow the same practice). It's one thing to make a mess of redundant copies on our own server. It's quite another thing to make a mess in your user's directory, for every user. This is not the same as saying do not distribute such jars in a binary distribution. That is a convenience that many projects offer ... but please let your user opt out of *only* being allowed to use the version you shipped. Thanks for your understanding. Jörg Craig
[jira] Updated: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated TRANSACTION-9: Fix Version/s: 2.0 [transaction] Add full file management capabilities to the FileResourceManager -- Key: TRANSACTION-9 URL: https://issues.apache.org/jira/browse/TRANSACTION-9 Project: Commons Transaction Issue Type: Improvement Environment: Operating System: All Platform: All Reporter: Peter Fassev Priority: Minor Fix For: 2.0 Attachments: filemanager.zip Hi, As stated in the doc the FileResourceManager is: A resource manager for streamable objects stored in a file system I agree, that this is a resource manager, but it could be easily extended, to support a full file management system. It will be very helpful to have additional methods like renameResource(), getResourceSize(), getResourceTime(), setResourceTime() etc. This are common file operations, which should be managed by the FileResourceManager. Further it will be very helpful to have (real) support for resource collections (folders). It will be necessary to distinguish between single resources (files) and collections (folders). Together, this features will enable a transactional access to any file based resources - for instance a document repository. Are there plans for such extensions and if not, will they actually fit in the goals of the transaction library? If not, please open the underlying structure, like the inner class TransactionContext, in order to add extensions the file management. For instance, it will be good to have a separate factory method, which creates the context. If you are interested in this proposal, I am ready to contribute to this project. I consider myself as an experienced java developer and I will be glad to help you. Best regards Peter Fassev -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
David Blevins david.blevins at visi.com writes: If someone needs JDK 1.3 versions of any spec jar, I'd be happy to help. OpenJPA had a similar request recently (JDK 1.3 version of JTA 1.1) and I made sure to do the final release of that spec with JDK 1.3. What exactly do you have in mind with your help offer? Is it publicly available then, maybe with a different naming? Please find my commit at http://svn.apache.org/viewvc?view=revrevision=493595. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DAEMON-45) [daemon] jsvc links to 32-bit JVM when compiled for (64-bit) sparcv9
[ https://issues.apache.org/jira/browse/DAEMON-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463146 ] Renaud Waldura commented on DAEMON-45: -- Let me restate the problem and maybe broaden the scope of this bug: there doesn't appear to be a way to run the 64-bit VM with jsvc 1.0.1. (The 64-bit VM is needed for heaps = 4GB.) The java switch -d64 is not recognized. I am building from the source included in the binary distribution of Tomcat 5.5.20. I fixed it my way by doing the following. I ran configure and edited the generated Makedefs file. I set CPU to sparcv9 and added -m64 to CFLAGS and LDFLAGS. This gets me an executable that is 64-bit and links to the 64-bit VM always. [daemon] jsvc links to 32-bit JVM when compiled for (64-bit) sparcv9 Key: DAEMON-45 URL: https://issues.apache.org/jira/browse/DAEMON-45 Project: Commons Daemon Issue Type: Bug Environment: Operating System: Solaris Platform: Sun Reporter: Jeff Carroll Attachments: ls.out This is a report on misbehavior of the search algorithm in native/location.c. I am building from the source included in the binary distribution of Tomcat 5.5.16. uname -a reports: SunOS iempsoa1 5.10 Generic_118822-27 sun4u sparc SUNW,Sun-Fire-880 config.guess reports sparc-sun-solaris2.10. ls -laR runs to 4k lines of text, so I will attach the file separately if I can figure out how. I'm not sure it's relevant, though. configure is identifying $host_cpu as sparc, and thus location.c finds the jvm.cfg for the 32-bit JVM, terminating with the messages 18/04/2006 15:35:12 7724 jsvc64 debug: Using default JVM in /usr/java/jre/lib/sp arc/client/libjvm.so 18/04/2006 15:35:12 7724 jsvc64 debug: Attemtping to load library /usr/java/jre/ lib/sparc/client/libjvm.so 18/04/2006 15:35:12 7724 jsvc64 error: Cannot dynamically link to /usr/java/jre/ lib/sparc/client/libjvm.so 18/04/2006 15:35:12 7724 jsvc64 error: ld.so.1: jsvc64: fatal: /usr/java/jre/lib /sparc/client/libjvm.so: wrong ELF class: ELFCLASS32 I intend to fix the problem for my purposes by hacking location_jvm_cfg[], but I know that's not a good solution for the general case. Everything works flawlessly on the 32-bit JVM. Given that, and given the disclaimers all over jvm.cfg, I don't know whether you'll consider this worth fixing or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Rahul Akolkar rahul.akolkar at gmail.com writes: URL: http://svn.apache.org/viewvc?view=revrev=494203 snip/ This change warrants a major release for [transaction]. Really? I don't mind if the current code is release as 2.0. But for such a minor change (though in the interface)? Please find my reasoning in https://issues.apache.org/jira/browse/TRANSACTION-11. Also I read the versioning guideline and can't see whether it really needs a major release (http://jakarta.apache.org/commons/releases/versioning.html): Generally speaking, an interface-compatible change will at most change the private interface of a component, or simply add classes, methods and attributes whose use is optional to both internal and external interface clients. Developers must perform a major release whenever the new release is not at least interface-compatible the previous release. IMHO the condition is fulfilled, so the rule does not fire. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
Craig McClanahan craigmcc at apache.org writes: Storing JAR files in your source repository (or pretty much any other scenario where you check in things that have been generated, instead of rebuilding them) has the following negative impacts: * Bypasses the normal mechanisms people use to verify that the bits they are depending on have not been corrupted (either accidentally or maliciously). A cautious downstream user will go directly to the origin for every package they depend on, and validate checksums and signatures. You are asking your downstream users to trust *you* to not have messed with these jar files. Good point. Side notes (not invalidating the point): Maven has switched off enforcing checksum match by default. Often projects would also not be buildable due to checksum mismatches in the dependencies. And: I have to trust Maven that it really checks every download. * Typically leads to a build environment where *only* the copy of the dependent jars in your repository are used. That makes life much harder for downstream users who might have several packages that need the same dependency, and need to be sure that their entire application * Creates redundant copies of shared dependencies in the build environment of your downstream users (if they use lots of packages that follow the same practice). It's one thing to make a mess of redundant copies on our own server. It's quite another thing to make a mess in your user's directory, for every user. I guess that was the major driver for Maven et al. but please let your user opt out of *only* being allowed to use the version you shipped. What do you have in mind? What's actually enforced? Does it relate to your impact 2 which is somewhat shortened? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 RC1
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote: -1, here's why... After reviewing the javadoc, I realised that having an inner class as an exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong in code. I propose that this exception is promoted to a top level class, and renamed to DirectoryWalkCancelledException. Since we need to build a new RC for Niall's fix, this shouldn't be a big problem if people agree. If people disagree with my analysis, then I will of course re-evaluate this -1 (for which I apologise...) I'm happy with how it is - but I also don't have an objection to you changing it either. Niall Stephen Henri Yandell wrote: I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc1/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Friday (if it makes it that far). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494275 - /jakarta/commons/proper/transaction/trunk/build.xml
Author: joerg
Date: Mon Jan 8 16:20:33 2007
New Revision: 494275
URL: http://svn.apache.org/viewvc?view=revrev=494275
Log:
follow hint of Ant:
[javac] The -source switch defaults to 1.5 in JDK 1.5 and 1.6.
[javac] If you specify -target 1.3 you now must also specify -source 1.3.
[javac] Ant will implicitly add -source 1.3 for you. Please change your build
file.
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?view=diffrev=494275r1=494274r2=494275
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Mon Jan 8 16:20:33 2007
@@ -30,6 +30,7 @@
property file=${basedir}/build.properties/
+ property name=compile.source value=1.3 /
property name=compile.target value=1.3 /
property name=compile.debug value=true /
property name=compile.deprecation value=true /
@@ -183,6 +184,7 @@
target name=build depends=prepare,detect description=Compiles the main
classes
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
@@ -194,6 +196,7 @@
target name=build-test depends=detect,build
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
@@ -205,6 +208,7 @@
target name=build-jca depends=build if=java1.4.present
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
@@ -216,6 +220,7 @@
target name=build-map-example depends=build-jca if=java1.4.present
javac destdir=${build.classes}
+ source=${compile.source}
target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 RC1
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote: -1, here's why... After reviewing the javadoc, I realised that having an inner class as an exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong in code. Could you say more about this, please? I happen to disagree on exceptions as inner classes being a bad idea; FileUpload has done this for years, without any problems. But I'm always interested in hearing new perspectives... -- Martin Cooper I propose that this exception is promoted to a top level class, and renamed to DirectoryWalkCancelledException. Since we need to build a new RC for Niall's fix, this shouldn't be a big problem if people agree. If people disagree with my analysis, then I will of course re-evaluate this -1 (for which I apologise...) Stephen Henri Yandell wrote: I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc1/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Friday (if it makes it that far). 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: [io] Inner class exception
Martin Cooper wrote: Could you say more about this, please? I happen to disagree on exceptions as inner classes being a bad idea; FileUpload has done this for years, without any problems. But I'm always interested in hearing new perspectives... I guess its stylistic, and therefore subjective. But I see an exception as a critical system object, and not one that should be relegated to inner class status. I pretty much only use inner classes for the internals of the main class. Details that shouldn't be exposed as part of the public API, except for very specialist users. Catching a cancellation exception doesn't seem to be a special case. For example, I also dislike Map.Entry, and think it should be MapEntry. (Well, actually I think map entries are the biggest mistake in the collections framework but thats another story...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
On 1/8/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Rahul Akolkar rahul.akolkar at gmail.com writes: URL: http://svn.apache.org/viewvc?view=revrev=494203 snip/ This change warrants a major release for [transaction]. Really? I don't mind if the current code is release as 2.0. But for such a minor change (though in the interface)? Please find my reasoning in https://issues.apache.org/jira/browse/TRANSACTION-11. snip/ Thanks, but I am not questioning the absolute validity of the change, just its validity for the proposed release. Also I read the versioning guideline and can't see whether it really needs a major release (http://jakarta.apache.org/commons/releases/versioning.html): Generally speaking, an interface-compatible change will at most change the private interface of a component, or simply add classes, methods and attributes whose use is optional to both internal and external interface clients. Developers must perform a major release whenever the new release is not at least interface-compatible the previous release. snap/ And this is not. You could convince yourself by running the changes through clirr, for instance. -Rahul IMHO the condition is fulfilled, so the rule does not fire. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jarfiles in svn
On 1/8/07, Joerg Heinicke [EMAIL PROTECTED] wrote:
Craig McClanahan craigmcc at apache.org writes:
Storing JAR files in your source repository (or pretty much any other
scenario where you check in things that have been generated, instead of
rebuilding them) has the following negative impacts:
* Bypasses the normal mechanisms people use to verify
that the bits they are depending on have not been corrupted
(either accidentally or maliciously). A cautious downstream
user will go directly to the origin for every package they
depend on, and validate checksums and signatures. You
are asking your downstream users to trust *you* to not
have messed with these jar files.
Good point.
Side notes (not invalidating the point): Maven has switched off enforcing
checksum match by default. Often projects would also not be buildable due
to
checksum mismatches in the dependencies. And: I have to trust Maven that
it
really checks every download.
Not necessarily ... people who are sufficiently concerned about this are
also setting up their own internal repositories, containing only the bits
they have vetted themselves, and with their own security settings.
* Typically leads to a build environment where *only* the
copy of the dependent jars in your repository are used.
That makes life much harder for downstream users who
might have several packages that need the same dependency,
and need to be sure that their entire application
* Creates redundant copies of shared dependencies in the
build environment of your downstream users (if they use
lots of packages that follow the same practice). It's one thing
to make a mess of redundant copies on our own server.
It's quite another thing to make a mess in your user's directory,
for every user.
I guess that was the major driver for Maven et al.
Someone had asked earlier about how Commons projects accomplished this goal
before Maven. The answer was a convention for using Ant build.xml scripts
that referenced a series of build.properties files containing definitions
for things like what commons-digester.jar should I use. The highest level
such file consulted was your ${user.home}/build.properties, so it was
reasonably easy to enforce global usage of common dependencies, as long as
all the build scripts used the same variable names.
Not perfect by any means, but it was minimally acceptable.
but please let your user opt out of *only* being allowed to use the
version
you shipped.
What do you have in mind? What's actually enforced? Does it relate to your
impact 2 which is somewhat shortened?
In your build script, don't hard code the build to use your particular
version of the dependency only. If I have my own version, I'm going to want
to use it universally.
Jörg
Craig
Re: [io] Inner class exception
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
Could you say more about this, please? I happen to disagree on
exceptions as
inner classes being a bad idea; FileUpload has done this for years, without
any problems. But I'm always interested in hearing new perspectives...
I guess its stylistic, and therefore subjective. But I see an exception
as a critical system object, and not one that should be relegated to
inner class status.
+1
} catch( DirectoryWalker.CancellationException ce) {
...
}
feels weak to me. Either we should catch CancellationException and its
a normal class, or we should catch IOException and it's package static
rather than public static.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote: Martin Cooper wrote: Could you say more about this, please? I happen to disagree on exceptions as inner classes being a bad idea; FileUpload has done this for years, without any problems. But I'm always interested in hearing new perspectives... I guess its stylistic, and therefore subjective. But I see an exception as a critical system object, and not one that should be relegated to inner class status. Inner classes are not inferior in any way, so there's no relegation going on. An inner class makes perfect sense for a class that has little relevance in isolation from another class, which is exactly the situation when you have a exception that is tied to its enclosing class. If the exception is specific to that class, what better way to document that than by making the exception an inner class? I pretty much only use inner classes for the internals of the main class. Details that shouldn't be exposed as part of the public API, except for very specialist users. Catching a cancellation exception doesn't seem to be a special case. As I mentioned above, there is nothing inferior about inner classes. If you choose to view them that way, well, that's a separate issue altogether. ;-) -- Martin Cooper For example, I also dislike Map.Entry, and think it should be MapEntry. (Well, actually I think map entries are the biggest mistake in the collections framework but thats another story...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
Could you say more about this, please? I happen to disagree on
exceptions as
inner classes being a bad idea; FileUpload has done this for years,
without
any problems. But I'm always interested in hearing new perspectives...
I guess its stylistic, and therefore subjective. But I see an exception
as a critical system object, and not one that should be relegated to
inner class status.
+1
} catch( DirectoryWalker.CancellationException ce) {
...
}
feels weak to me.
Weak why? To me, it makes the code very explicit about what is being
cancelled. It also, by the way, allows for other classes to have a
CancellationException without having to make up some other name, because the
enclosing class scopes the exception class name and allows its reuse in
other classes. It seems like an eminently suitable way of naming / scoping
tightly coupled classes such as we see with these types of exceptions.
--
Martin Cooper
Either we should catch CancellationException and its
a normal class, or we should catch IOException and it's package static
rather than public static.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Martin Cooper [EMAIL PROTECTED] wrote:
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
Could you say more about this, please? I happen to disagree on
exceptions as
inner classes being a bad idea; FileUpload has done this for years,
without
any problems. But I'm always interested in hearing new perspectives...
I guess its stylistic, and therefore subjective. But I see an exception
as a critical system object, and not one that should be relegated to
inner class status.
+1
} catch( DirectoryWalker.CancellationException ce) {
...
}
feels weak to me.
Weak why?
Because I'm not used to it I suspect. It's not a common idiom so not
something my eyes naturally parse, and if I was writing the code I
suspect it would take a bit longer to write. Not char-wise, I mean in
terms of realising what I was meant to catch.
Stephen mentioned the javadoc. Looking at that, I doubt I'd be
catching DirectoryWalker.CancellationException anyway - the method
that it is thrown from throws IOException. The
DirectoryWalker.CancellationException isn't in its contract, except as
an argument passed in.
The examples in the Javadoc look bad btw. They refer to CancelException and not
DirectoryWalker.CancellationException.
To me, it makes the code very explicit about what is being
cancelled. It also, by the way, allows for other classes to have a
CancellationException without having to make up some other name, because the
enclosing class scopes the exception class name and allows its reuse in
other classes. It seems like an eminently suitable way of naming / scoping
tightly coupled classes such as we see with these types of exceptions.
Good arguments - though they just make me think in terms of a more
specific class name - WalkCancelledException.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-10) [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 onwards
[
https://issues.apache.org/jira/browse/JXPATH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463199
]
Paul Parisi commented on JXPATH-10:
---
[jxpath] JXPath 1.1 code using custom functions failing when run in 1.2
onwards
---
Key: JXPATH-10
URL: https://issues.apache.org/jira/browse/JXPATH-10
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: PC
Reporter: Paul Parisi
Priority: Blocker
Fix For: 1.3
We have recently attempted to upgrade from a 1.1 release of jxpath
to 1.2 and found a great deal of our jxpath code fails to run correctly.
We isolated the problem to relating to the use of Custom Extension
Functions and have included sample junit test case snippets that should
demonstrate the issue clearly.
The background on what we are trying to do with jxpath is as follows
(included so its clear on what we are trying to use jxpath to achieve):
Within our project, we make extensive use of Custom Extension Functions in
JXPath.
We also use JXPath variables significantly, in combination with these
functions,
that often take a JXPath variable as an argument(s) to the function.
We now rely heavily on the use of the ExpressionContext interface as the
first
argument to many of our functions. The reason for this is that we need a
convienient way to obtain access to 'original' object references within the
context invoked by the function (as you would expect).
However, we have also begun using a very useful combination of features, which
the API supports in version 1.1, where the first argument always defines the
ExpressionContext interface (which isn't really part of the method signature -
from a caller perspective), and a 2nd argument as 'Object' type. Within body
of
the function, we then cast the object of the 2nd argument as a NodeSet (or
define the NodeSet type within the method signature - either appears to work),
which provides us with access to the pointers for the object.
As previously mentioned, a jxpath variable is passed from the caller of the
function (received via the 2nd argument in the method signature), which is
automatically resolved, by jxpath, to the object itself.
The benefit of casting the object to NodeSet (interface) enables us to
retrieve
the first pointer in the NodeSet list. The first pointer concerns us, as it
refers to the String value passed to the argument of the function which we
need
access to. The object reference itself is of little concern in this case, as
once we have access to the variable name sent to the function, we can access
the
object via the ExpressionContext.
This all works fine in jxpath 1.1, however, in version 1.2 this functionality
is
now broken, since our objects are no longer being cast to NodeSet (previously
achieved via the internal implementation of jxpath NodeSet using a
SimpleNodeSet
- as per inspecting jxpath 1.1 source code).
Note on the use of ExpressionContext: For those methods that declare the
ExpressionContext interface (which must be the first argument, if used), as
part
of the argument list, the method signature from the caller perspective,
excludes
it from the argument list, as it is implied by jxpath. In other words, there
will be one less argument from the caller when the interface is used. In the
case where this interface was the only argument, which is common, then the
caller would be invoking a zero-argument method. This is behaviour we expect.
Here is a simplified example of one of our functions using the techniques
discussed:-
public static void deleteSomeObject(ExpressionContext expContext, Object obj)
{
// create a local jxpath context to retrieve values for jxpath variables
JXPathContext localContext = expContext.getJXPathContext();
// Nodeset of the object passed to method
NodeSet nodeset = (NodeSet)obj;
// Retrieve variable name passed to function
String declaredVariable = nodeset.getPointers().get(0).toString();
Object objectToDelete = null;
// If this method was passed the $obj1 var to delete, then retrieve 'Object
Type
1' via $obj1 variable
if (declaredVariable.equals($obj1)) {
objectToDelete = (ObjectType1)localContext.getValue($obj1);
}
// If this method was passed the $obj2 var to delete, then retrieve
'Object
Type 2' via $obj2 variable
if (declaredVariable.equals($obj2)) {
objectToDelete = (ObjectType2)localContext.getValue($obj2);
}
collectionOfSomeObjects.delete(objectToDelete);
}
Which would be used (called) in the following way:-
...
// add to collection
ObjectType1 objectType1 = new
RE: [sandbox] Using commons-skin for all components
Hi Rahul, Rahul Akolkar wrote on Monday, January 08, 2007 8:47 PM: On 1/8/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Dennis, Dennis Lundberg wrote: [snip] - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. I tried to look at this, but where's the commons-sandbox parent pom? snip/ In trunks-sandbox, more specifically: https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbo x/pom.xml IMHO it makes more sense to have an own commons-sandbox-parent trunk (like any other sandbox component). That way you don't have to checkout the complete sandbox and additionally you get the possibility to create a release for the POM ... or is that not supposed to happen for the sandbox parent POM ? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-10) [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 onwards
[
https://issues.apache.org/jira/browse/JXPATH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463204
]
Paul Parisi commented on JXPATH-10:
---
Hello Matt,
We originally logged this defected some time back. I note you are interested
in knowing our
progress from your comments.
Since logging this defect we stopped using jxpath 1.2 and commented out all the
unit tests we had
developed that depending on its functionality (we cannot run two versions of
jxpath in our
build system) So essentially we have not been able to upgrade jxpath, however
we still would like
to do this as we eventually. If you are able to provide a workaround we would
be keen to try it out.
regards,
Paul Parisi
[jxpath] JXPath 1.1 code using custom functions failing when run in 1.2
onwards
---
Key: JXPATH-10
URL: https://issues.apache.org/jira/browse/JXPATH-10
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: PC
Reporter: Paul Parisi
Priority: Blocker
Fix For: 1.3
We have recently attempted to upgrade from a 1.1 release of jxpath
to 1.2 and found a great deal of our jxpath code fails to run correctly.
We isolated the problem to relating to the use of Custom Extension
Functions and have included sample junit test case snippets that should
demonstrate the issue clearly.
The background on what we are trying to do with jxpath is as follows
(included so its clear on what we are trying to use jxpath to achieve):
Within our project, we make extensive use of Custom Extension Functions in
JXPath.
We also use JXPath variables significantly, in combination with these
functions,
that often take a JXPath variable as an argument(s) to the function.
We now rely heavily on the use of the ExpressionContext interface as the
first
argument to many of our functions. The reason for this is that we need a
convienient way to obtain access to 'original' object references within the
context invoked by the function (as you would expect).
However, we have also begun using a very useful combination of features, which
the API supports in version 1.1, where the first argument always defines the
ExpressionContext interface (which isn't really part of the method signature -
from a caller perspective), and a 2nd argument as 'Object' type. Within body
of
the function, we then cast the object of the 2nd argument as a NodeSet (or
define the NodeSet type within the method signature - either appears to work),
which provides us with access to the pointers for the object.
As previously mentioned, a jxpath variable is passed from the caller of the
function (received via the 2nd argument in the method signature), which is
automatically resolved, by jxpath, to the object itself.
The benefit of casting the object to NodeSet (interface) enables us to
retrieve
the first pointer in the NodeSet list. The first pointer concerns us, as it
refers to the String value passed to the argument of the function which we
need
access to. The object reference itself is of little concern in this case, as
once we have access to the variable name sent to the function, we can access
the
object via the ExpressionContext.
This all works fine in jxpath 1.1, however, in version 1.2 this functionality
is
now broken, since our objects are no longer being cast to NodeSet (previously
achieved via the internal implementation of jxpath NodeSet using a
SimpleNodeSet
- as per inspecting jxpath 1.1 source code).
Note on the use of ExpressionContext: For those methods that declare the
ExpressionContext interface (which must be the first argument, if used), as
part
of the argument list, the method signature from the caller perspective,
excludes
it from the argument list, as it is implied by jxpath. In other words, there
will be one less argument from the caller when the interface is used. In the
case where this interface was the only argument, which is common, then the
caller would be invoking a zero-argument method. This is behaviour we expect.
Here is a simplified example of one of our functions using the techniques
discussed:-
public static void deleteSomeObject(ExpressionContext expContext, Object obj)
{
// create a local jxpath context to retrieve values for jxpath variables
JXPathContext localContext = expContext.getJXPathContext();
// Nodeset of the object passed to method
NodeSet nodeset = (NodeSet)obj;
// Retrieve variable name passed to function
String declaredVariable = nodeset.getPointers().get(0).toString();
Object objectToDelete = null;
// If this method was passed the $obj1 var to delete, then retrieve 'Object
Type
1' via $obj1 variable
if
Re: [io] Inner class exception
On 1/9/07, Henri Yandell [EMAIL PROTECTED] wrote:
} catch( DirectoryWalker.CancellationException ce) {
Consider importing CancellationException and not or not only
DirectoryWalker. :-)
Jochen
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
