Re: REPOST [attributes 2.2] Missing optional package Extension
On 1/3/07, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'm using commons-attributes with Spring on a Java 1.4 application. I've included commons-attributes-api 2.2 (from maven repo) I get this Tomcat exception on startup : LifecycleException: Missing optional package Extension[ant, implementationURL= http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar, implementationVersion=1.5] The commons-attributes MANIFEST contains those lines : Extension-List: ant qdox ant-Extension-Name: ant ant-Implementation-Version: 1.5 ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1.5.jar I don't know what this Extension-List is and why is it required by commons-attributes. AFAIK, the API doesn't require those libs anyway (only the compiler do). Is this a bug, and what would be a workaround ? AFAIK there is no development anymore on commons-attributes, so I can't ask for a 2.2.1 to correct this. How to handle this Extension-List ? I've added ant and qodx in my WEB-INF/lib with no result. I've no idea on the specific problem you're facing, but if a solution turns up I could try to push out a 2.2.1 release to correct it. I imagine removing the bits from the manifest would solve things - have you tried deleting them to see if things work? That'd be my first step. Then I'd google around to see if I can figure out what they're for. Then either suggest a new release or a workaround. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-71) Ponter.asPath() return values not always correct
[
https://issues.apache.org/jira/browse/JXPATH-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462169
]
John Attwood commented on JXPATH-71:
Hi,
Thanks for looking into this. I've rerun my tests against the latest
build and they all pass.
However, the current stable release still appears to be 1.2 final, which
is the one that contains the bug. I'm not sure that I'd be allowed to
use a nightly build with production code, so when do you think we can
expect v1.3 to be released?
Thanks,
John.
https://issues.apache.org/jira/browse/JXPATH-71?page=com.atlassian.jira.plugin.s
ystem.issuetabpanels:comment-tabpanel#action_12462092 ]
and target is a collection. The path returned always has a final subscript
equal
to the size of the collection, although Pointer.getValue() still returns the
correct element in each case. Below are two classes and a JUnit testcase which
reproduce the bug and isolate it to the case where the path starts with '//'
and
the target is a collection.
for my JXPath-based object trees. It does't affect the main app, as getValue()
always returns the correct node, but in my explorer it only ever highlights the
last element in any collection (the objects in my trees aren't always unique so
the path is only way to identify them individually and allow the matching nodes
to be highlighted).
//
/
TestPointerToPath.java
///
https://issues.apache.org/jira/secure/Administrators.jspa
Ponter.asPath() return values not always correct
Key: JXPATH-71
URL: https://issues.apache.org/jira/browse/JXPATH-71
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: WInXP, Java 1.5, Eclipse 3.2
Reporter: John Attwood
String returned by Pointer.asPath() is incorrect when path starts with '//'
and target is a collection. The path returned always has a final subscript
equal to the size of the collection, although Pointer.getValue() still
returns the correct element in each case. Below are two classes and a JUnit
testcase which reproduce the bug and isolate it to the case where the path
starts with '//' and the target is a collection.
I found this problem whilst trying to write the equivalent of XPathExplorer
for my JXPath-based object trees. It does't affect the main app, as
getValue() always returns the correct node, but in my explorer it only ever
highlights the last element in any collection (the objects in my trees aren't
always unique so the path is only way to identify them individually and allow
the matching nodes to be highlighted).
Otherwise an excellent, easy-to-use and really useful package.
/// Parent.java
//
package test;
import java.util.ArrayList;
public class Parent {
private int id;
private ArrayListChild kids;
public Parent(int id) {
this.id = id;
this.kids = new ArrayListChild();
}
public int getId() {
return id;
}
public ArrayListChild getKids() {
return kids;
}
public void addKid(Child kid) {
kids.add(kid);
}
public void setId(int id) {
this.id = id;
}
public void setKids(ArrayListChild kids) {
this.kids = kids;
}
}
/// Child.java
/
package test;
public class Child {
private int id;
public Child(int id) {
this.id = id;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
}
///
TestPointerToPath.java
///
package test;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
import junit.framework.TestCase;
import org.apache.commons.jxpath.JXPathContext;
import org.apache.commons.jxpath.Pointer;
public class TestPonterToPath extends TestCase {
private Parent parent;
private SetString expectedPaths, actualPaths;
private SetObject actualObjects, expectedObjects;
private JXPathContext ctx;
private static final int SIZE = 4;
public void setUp() {
[EMAIL PROTECTED]: Project commons-lang (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-lang has an issue affecting its community integration. This issue affects 190 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - anakia : Essentially an XML transformation tool, Anakia uses JDOM and... - ant-embed-optional : Java based build tool - ant-xdocs-proposal : Java based build tool - apache-ldapber-provider : Apache Directory Project - apacheds-core : Apache Directory Server - apacheds-main : Apache Directory Server - apollo : Apollo Project - asn1-ber : Apache ASN.1 Tools - authx-example : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - cargo : Cargo provides a Java API to manipulate Java Containers - checkstyle : Java style checker - commons-cli : Commons CLI Package - commons-cli2 : Commons CLI Package - commons-configuration : Jakarta commons - commons-dbcp : Database Connection Pool - commons-email : Commons Email Package - commons-fileupload : Commons File Upload Package - commons-io : Commons I/O Utility Package - commons-jci : Commons JCI - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - commons-jxpath : XPath traversal of JavaBeans - commons-lang : utilities for the classes that are in java.lang's hierarchy - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - db-torque : Persistence Layer - db-torque-gen : Persistence Layer - excalibur-component : Repository of reusable components. - excalibur-cornerstone-connection-api : Repository of reusable components. - excalibur-cornerstone-connection-impl : Repository of reusable components. - excalibur-cornerstone-datasources-impl : Repository of reusable components. - excalibur-cornerstone-scheduler-impl : Repository of reusable components. - excalibur-cornerstone-threads-api : Repository of reusable components. - excalibur-cornerstone-threads-impl : Repository of reusable components. - excalibur-datasource : Repository of reusable components. - excalibur-event : Repository of reusable components. - excalibur-event-api : Repository of reusable components. - excalibur-event-impl : Repository of reusable components. - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-api : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable
[EMAIL PROTECTED]: Project commons-lang (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-lang has an issue affecting its community integration. This issue affects 190 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - anakia : Essentially an XML transformation tool, Anakia uses JDOM and... - ant-embed-optional : Java based build tool - ant-xdocs-proposal : Java based build tool - apache-ldapber-provider : Apache Directory Project - apacheds-core : Apache Directory Server - apacheds-main : Apache Directory Server - apollo : Apollo Project - asn1-ber : Apache ASN.1 Tools - authx-example : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - cargo : Cargo provides a Java API to manipulate Java Containers - checkstyle : Java style checker - commons-cli : Commons CLI Package - commons-cli2 : Commons CLI Package - commons-configuration : Jakarta commons - commons-dbcp : Database Connection Pool - commons-email : Commons Email Package - commons-fileupload : Commons File Upload Package - commons-io : Commons I/O Utility Package - commons-jci : Commons JCI - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - commons-jxpath : XPath traversal of JavaBeans - commons-lang : utilities for the classes that are in java.lang's hierarchy - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - db-torque : Persistence Layer - db-torque-gen : Persistence Layer - excalibur-component : Repository of reusable components. - excalibur-cornerstone-connection-api : Repository of reusable components. - excalibur-cornerstone-connection-impl : Repository of reusable components. - excalibur-cornerstone-datasources-impl : Repository of reusable components. - excalibur-cornerstone-scheduler-impl : Repository of reusable components. - excalibur-cornerstone-threads-api : Repository of reusable components. - excalibur-cornerstone-threads-impl : Repository of reusable components. - excalibur-datasource : Repository of reusable components. - excalibur-event : Repository of reusable components. - excalibur-event-api : Repository of reusable components. - excalibur-event-impl : Repository of reusable components. - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-api : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable
Re: REPOST [attributes 2.2] Missing optional package Extension
According to SVN log, the manifest has been added by bayard. The maven generated manifest is not used (why ?) I also notice maven.compiler.target has been set to 1.4 during 2.2 (rev 410143 by leosutic) that will break backward compatibility : I'm using commons-attributes on other projects on JRE 1.3. I've tested some changes from commons-attributes trunk : change maven.compiler.source and maven.compiler.target to 1.3 in project.properties remove manifest.mf from api sub-project remove dependencies in api/project.xml (as they are only required by compiler) With those changes, my webapp launch fine and run as expected. From what I've read, Extension-List is used to allow downloading of libs at runtime when not available in classpath. As ant and qdox manifest don't declare themself as extensions, the extension resolution fails. I'd suggest a new release as compatibility with 1.3 is blocking for me to upgrade. Nico. 2007/1/4, Henri Yandell [EMAIL PROTECTED]: On 1/3/07, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'm using commons-attributes with Spring on a Java 1.4 application. I've included commons-attributes-api 2.2 (from maven repo) I get this Tomcat exception on startup : LifecycleException: Missing optional package Extension[ant, implementationURL= http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar, implementationVersion=1.5] The commons-attributes MANIFEST contains those lines : Extension-List: ant qdox ant-Extension-Name: ant ant-Implementation-Version: 1.5 ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1.5.jar I don't know what this Extension-List is and why is it required by commons-attributes. AFAIK, the API doesn't require those libs anyway (only the compiler do). Is this a bug, and what would be a workaround ? AFAIK there is no development anymore on commons-attributes, so I can't ask for a 2.2.1 to correct this. How to handle this Extension-List ? I've added ant and qodx in my WEB-INF/lib with no result. I've no idea on the specific problem you're facing, but if a solution turns up I could try to push out a 2.2.1 release to correct it. I imagine removing the bits from the manifest would solve things - have you tried deleting them to see if things work? That'd be my first step. Then I'd google around to see if I can figure out what they're for. Then either suggest a new release or a workaround. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JXPATH-75) The dependency for xerces in commons-jxpath-1.2.pom is too old
The dependency for xerces in commons-jxpath-1.2.pom is too old -- Key: JXPATH-75 URL: https://issues.apache.org/jira/browse/JXPATH-75 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.2 Final Environment: java version 1.5.0_04 maven2 commons-configuration-1.3 commons-jxpath-1.2 spring-context-2.0.1 Reporter: Dmitry Katsubo Priority: Minor The following dependency in commons-jxpath-1.2.pom (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-jxpath/commons-jxpath/1.2/commons-jxpath-1.2.pom) is out-of-date: dependency groupIdxerces/groupId artifactIdxerces/artifactId version1.2.3/version /dependency The side effect from this dependency is, that some component, that implicitly uses xerces, may fail with this old xerces version. For example, I am using commons-configuration with spring framework which assumes, that XML parser is able to make XSD verification of configuration files, but xerces-1.2.3 is not able to do this. Solutions are: a) remove all dependencies from commons-jxpath.pom, related with xerces (I hope, most of the community uses at least java1.5, or one may include dependency on xerces in his .pom, as in (c) ) b) update version of xerces in commons-jxpath.pom up to 2.4.0 c) include dependency in your .pom, that overrides version of xerces -- 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]
[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 25 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-04012007.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 1904012007, vmgump.apache.org:vmgump-public:1904012007 Gump E-mail Identifier (unique within run) #31. -- 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 25 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-04012007.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 1904012007, vmgump.apache.org:vmgump-public:1904012007 Gump E-mail Identifier (unique within run) #31. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SANDBOX-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462198 ] Christian Grobmeier commented on SANDBOX-183: - Hi, it seems difficult to integrate this in the existing codebase. It looks like we would have to throw away the old zip implementation and use this one, if we want this feature. Please help if i am wrong. For the memory problem: wouldn't it be easier just to expand the zipfile in an temp directory, take the intrnal catalog to see what files we need again and rebuild the whole stuff? I think this is the way winzip handles this. This would be quite safe and the old file would't get corrupt in case of any trouble. This strategy would also allow us to delete from the zip package. No? Cheers, Chris. Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Fix For: Nightly Builds Attachments: myzip.zip Compress should be able to modify existing ZipFiles. -- 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]
[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 25 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-04012007.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 1904012007, vmgump.apache.org:vmgump-public:1904012007 Gump E-mail Identifier (unique within run) #37. -- 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 25 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-04012007.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 1904012007, vmgump.apache.org:vmgump-public:1904012007 Gump E-mail Identifier (unique within run) #37. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-311) test
test Key: LANG-311 URL: https://issues.apache.org/jira/browse/LANG-311 Project: Commons Lang Issue Type: Test Affects Versions: 2.2 Reporter: Hayo just a test. yesterday submitting did not work -- 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-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462205 ] Mario Ivankovits commented on SANDBOX-183: -- wouldn't it be easier just to expand the zipfile in an temp directory Yea, I am a little bit conservative about this topic too. How can we know that we do not damage a zip in any case, though, the algorithmic used currently seems not that complicated - I don't know. We should give it a try, maybe. Instead of incorporating it into the existing codebase, can't we add it as alternative implementation? Something like ZipEx method. So that we can have both methods (direct alteration and unzip/zip through temp dir). Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Fix For: Nightly Builds Attachments: myzip.zip Compress should be able to modify existing ZipFiles. -- 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: (LANG-311) test
[ https://issues.apache.org/jira/browse/LANG-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayo updated LANG-311: -- Priority: Trivial (was: Major) test Key: LANG-311 URL: https://issues.apache.org/jira/browse/LANG-311 Project: Commons Lang Issue Type: Test Affects Versions: 2.2 Reporter: Hayo Priority: Trivial just a test. yesterday submitting did not work -- 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-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462206 ] Christian Grobmeier commented on SANDBOX-183: - Adding it as altnerate would be possible. Archivers are registered at the beginning of ArchiverFactory. There we could add this implementation. Lets name it ZipQuick cause it may be more quick but a bit unsure? The new stuff must implement the archiver-interfaces when integrating it (all in org.apache.commons.compress) Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Fix For: Nightly Builds Attachments: myzip.zip Compress should be able to modify existing ZipFiles. -- 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-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462210 ] Christian Grobmeier commented on SANDBOX-183: - another thing: this newimplementation does depend on commons IO. I am not sure, but i think there was a discussion in the past that this is not a good idea. This copy method used is also somewhere in the compress code when i remember correct. I think its CompressUtils or something like that. Btw, you can add this implemetnation at runtime via the static addArchiver() method in the factory. May be helpful... And. for delete/modification support the Archiver-interfaces must be extended with such methods too- no big deal. Idea was: - get an list of ArchiveEntrys with: list() or entries() - do: delete(ArchiveEntry entry) for each entry you dont want any longer - do. update() to rewrite your zip file Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Fix For: Nightly Builds Attachments: myzip.zip Compress should be able to modify existing ZipFiles. -- 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] Created: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2, 2.1
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day); //
or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default: +
def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only in
Berlin. Setting the Locale to any other value has no effect on that. So i ask
myself, what results other central european users get. Setting the Timezone to
GMT+2 extracts exactly the high summer times in 1945 and 1947 (MEHSZ). (See
below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This might
depend on my environment, so this task should be tested by others (with their
local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET until 1947-10-05 3:00:00 CEST
1948-04-182:00:00 CET until 1948-10-03 3:00:00 CEST
1949-04-102:00:00 CET until 1949-10-02 3:00:00 CEST
b) High summer time, Advance to CET: 2 hours (GMT+3)
1947-05-113:00:00 CEST until 1947-06-29 3:00:00 MEHSZ
c) From 1950 to 1979 no Summer times
d) 1980 to now (most of central europe)
1980-04-062:00:00 CET until 1980-09-28 3:00:00 CEST
...
ongoing until today
--
This message is automatically generated by JIRA.
-
If you think it was sent
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462231
]
Hayo commented on LANG-312:
---
I can almost instantly comment myself:
It really is the java.util.Date vs. java.util.Calendar problem. Creating a
java.util.Date with Calendar does not produce the problem. See code snippet
below:
Calendar c = Calendar.getInstance(TimeZone.getTimeZone(CET),
Locale.GERMANY);
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
c.set(1900 + year, month, day);
java.util.Date dt = c.getTime();
// not: java.util.Date dt = new java.util.Date(year, month,
day);
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
TimeZone.getTimeZone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default: +
def + CET: + cet);
}
}
}
}
Nonetheless i see an issue with DateFormatUtils. While this subtile problem
will persist (and already did cost thousands of Euros only in our project), the
API documentation _must_ state in every param description, that the Date must
be instantiated by java.util.Calendar, not by java.util.Date.
Nicer would be to deprecate all signatures with Date and only allow Calendar
instances as parameter.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation
Re: REPOST [attributes 2.2] Missing optional package Extension
On 1/4/07, nicolas de loof [EMAIL PROTECTED] wrote: According to SVN log, the manifest has been added by bayard. The maven generated manifest is not used (why ?) These are for the Ant build - they're the ones that Maven generated for me. Seem to recall that attributes didn't like building on the Mac, so this was done on a Debian Linux box with Sun 1.4.2 and Maven 1.0.2. Unless manifest.mf is a name convention; they're not used for the Maven build. I also notice maven.compiler.target has been set to 1.4 during 2.2 (rev 410143 by leosutic) that will break backward compatibility : I'm using commons-attributes on other projects on JRE 1.3. I've tested some changes from commons-attributes trunk : change maven.compiler.source and maven.compiler.target to 1.3 in project.properties Does it compile under 1.3 for you (using Ant I presume)? I'm wondering why the move to 1.4 was done, maybe there's a call to a 1.4 only method in there somewhere. remove manifest.mf from api sub-project Should be unnecessary. remove dependencies in api/project.xml (as they are only required by compiler) +1. With those changes, my webapp launch fine and run as expected. From what I've read, Extension-List is used to allow downloading of libs at runtime when not available in classpath. As ant and qdox manifest don't declare themself as extensions, the extension resolution fails. I'd suggest a new release as compatibility with 1.3 is blocking for me to upgrade. Sounds good - once we grok why it was moved to 1.4. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Deleted: (LANG-311) test
[ https://issues.apache.org/jira/browse/LANG-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell deleted LANG-311: --- test Key: LANG-311 URL: https://issues.apache.org/jira/browse/LANG-311 Project: Commons Lang Issue Type: Test Reporter: Hayo Priority: Trivial just a test. yesterday submitting did not work -- 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]
[Collections] Equator interface
Java has Comparable and Comparator to compare objects. Object has an equals() method. But what are we meant to do when and object has multiple ways of being equal? Consider an database row that has a name, code and a value. Equality could be based on * database id * code * name and code * case-insensitive name Any of these could be appropriate in different situations - in the same way we use Comparators, we should be able to use Equators. When extended to collections, this allows us to search for specific values (with an EqualsPredicate that takes an Equator), and implement Maps and Sets that use specific equators to determine uniqueness (a HashEquator interface may also be defined for this). However, it is also useful for general coding and equality checking. Does this mean it's suitable for Lang (not really knowing anything about that project)? Is there a Predicate class in Lang? If an Equator is determined to be something worthwhile for the next (generic) version of Collections, I can provide interfaces, default implementations tests etc. Cheers Stephen Kestle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] new patches
Greetings all, I've been spending some time recently in commons-email, as it's one of my interests and I've done lots of email work in the past. I notice that there are a few issues in JIRA that are easily fixed and that would make it more useful in the short term. Also, from the open issues there is a big need for improvements to how it handles email in different charsets. I've put a few patches up for consideration -- specifically for EMAIL-35 and EMAIL-60 -- and I was hoping someone could take a few moments to look at them, offer suggestions, etc. Thanks! --Ben
[sandbox] Using commons-skin for all components
Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: 1. Make various changes to the sandbox-parent, which is currently located in sandbox-trunk: - Remove local style rules - Remove stuff that is inherited from commons-parent, most notably maven-classic-skin 2. Change pom.xml and site.xml for many sandbox components - Make sure inheritance is correct - Align navigation structure - Remove stuff that is inherited from sandbox-parent 3. Re-publish the sites for all sandbox components - Do mvn site:deploy for all sandbox components - Would like to move sandbox-parent to its own directory in SVN - If we feel that it's necessary at this time: release commons-skin, commons-parent and sandbox-parent Does this sound OK to you? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jxpath] 1.3
Hi, for those of you who haven't encountered me lurking on commons-dev for the past year or two, I'm a member of the Ant PMC and a commons user. I'm also a committer to commons-openpgp in the sandbox but haven't done much there (yet?). :( Finally, I suffered a burst of commons-collections contributions last summer or sometime thereabouts. Now that I've (hopefully sufficiently) introduced myself, I'll get to the point: I see that there is some user demand for a new release of jxpath; indeed I am a user who would also benefit from a release, always preferable to explaining to your peers why you insist on using nightlies... ;) I'd like to offer to help with whatever tasks are necessary to push jxpath to a 1.3 release. I think Dmitri still lurks here but best I can tell he's got other things to do. Plus I suppose you eventually don't really feel like continuing to look at the same old code, impressive though the jxpath code is... Can somebody (Henri?) offer advice on what I and/or other members of the (user and/or Apache committer) community might do to get the ball rolling? br, Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (NET-148) Relaxed condition in __getReply causes other failures.
Relaxed condition in __getReply causes other failures.
--
Key: NET-148
URL: https://issues.apache.org/jira/browse/NET-148
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Reporter: Matthew Simoneau
In FTP.java's __getReply() method, this do/while loop reads multi-line
responses from the server:
do
{
line = _controlInput.readLine();
...
}
while (!(line.length() = 4 line.charAt(3) != '-'
Character.isDigit(line.charAt(0;
// This is too strong a condition because of non-conforming ftp
// servers like ftp.funet.fi which sent 226 as the last line of a
// 426 multi-line reply in response to ls /. We relax the
condition to
// test that the line starts with a digit rather than starting with
// the code.
// line.startsWith(code)));
}
Note the comment and the commented-out termination condition. I think the
relevant spec is http://www.ietf.org/rfc/rfc0959.txt and the section is 4.2.
FTP REPLIES. This is causing problems with the return from the STAT command
from Geocities' FTP servers. Here is an example reply.
211- ftp.us.geocities.com FTP server status:
Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007
Connected to 144.212.217.85
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
57 traffic bytes received in 0 transfers
733 traffic bytes transmitted in 0 transfers
834 traffic bytes total in 0 transfers
211 End of status
Note that the line 0 data bytes total in 0 files starts with a digit, but it
isn't a reply code. This prematurely halts reading of lines from the server,
and the remaining lines will look like a reply from the next command.
--
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: [jxpath] 1.3
Matt Benson wrote: Can somebody (Henri?) offer advice on what I and/or other members of the (user and/or Apache committer) community might do to get the ball rolling? Some things to think about: - updating the license in each source file to the latest ASF standards - update the xdocs site generation to fit better with other components: -- see http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture -- update home page with documentation/releases/support section -- add cvs-usage.xml, issue-tracking.xml - compare project.xml to other components Generally, take a look at [io] or [lang], compare and update as appropriate. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ang] pre 2.3 build
Henri Yandell wrote: Anything need fixing up before doing the real build? I don't like the new table on the home page. I think it provides too much information, and mainly information that isn't that relevant. Its also inconsistent with the other similar commons sites, notably in that releases is now above documentation. (Yes, I know this is minor, but all this helps consistency. If we do change this, we should change it elsewhere too.) If it is to be kept then perhaps the release notes column should always have the text 'release notes'? and the javadoc column 'javadoc'. Perhaps there should be a download column? Also, javadoc for 1.0 isn't online, so a symlink to 1.0.1 would need to be created. And if we do keep it, then perhaps the releases and documentation section should be merged. I think the best solution would be to move the data to a separate release history page? The home page then just references the download and javadoc of the latest version, probably in a combined releases and documentation section. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r492832 - in /jakarta/commons/proper/lang/trunk/xdocs: index.xml release2_0.xml
Author: scolebourne Date: Thu Jan 4 16:21:33 2007 New Revision: 492832 URL: http://svn.apache.org/viewvc?view=revrev=492832 Log: Rename releasenotes to release to match [collections] and fix text within Added: jakarta/commons/proper/lang/trunk/xdocs/release2_0.xml (contents, props changed) - copied, changed from r492356, jakarta/commons/proper/lang/trunk/xdocs/releasenotes2_0.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/xdocs/index.xml?view=diffrev=492832r1=492831r2=492832 == --- jakarta/commons/proper/lang/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/lang/trunk/xdocs/index.xml Thu Jan 4 16:21:33 2007 @@ -51,7 +51,7 @@ trtd2.3/tdtdPending/tdtda href=api-2.3/api-2.3/a/tdtda href=upgradeto2_3.htmlupgrade to 2.3/a/td/tr trtd2.2/tdtd04/Oct/06/tdtda href=api-2.2/api-2.2/a/tdtda href=upgradeto2_2.htmlupgrade to 2.2/a/td/tr trtd2.1/tdtd13/Jun/06/tdtda href=api-2.1/api-2.1/a/tdtda href=upgradeto2_1.htmlupgrade to 2.1/a/td/tr -trtd2.0/tdtd02/Sep/03/tdtda href=api-2.0/api-2.0/a/tdtda href=releasenotes2_0.htmlrelease notes for 2.0/a/td/tr +trtd2.0/tdtd02/Sep/03/tdtda href=api-2.0/api-2.0/a/tdtda href=release2_0.htmlrelease notes for 2.0/a/td/tr trtd1.0.1/tdtd25/Nov/02/tdtda href=api-1.0.1/api-1.0.1/a/tdtda href=http://archive.apache.org/dist/jakarta/commons/lang/old/v1.0.1/RELEASE-NOTES.txt;upgrade to 1.0.1/a/td/tr trtd1.0/tdtd04/Oct/02/tdtda href=api-1.0/api-1.0/a/tdtda href=http://archive.apache.org/dist/jakarta/commons/lang/old/v1.0/RELEASE-NOTES.txt;release notes for 1.0/a/td/tr /table Copied: jakarta/commons/proper/lang/trunk/xdocs/release2_0.xml (from r492356, jakarta/commons/proper/lang/trunk/xdocs/releasenotes2_0.xml) URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/xdocs/release2_0.xml?view=diffrev=492832p1=jakarta/commons/proper/lang/trunk/xdocs/releasenotes2_0.xmlr1=492356p2=jakarta/commons/proper/lang/trunk/xdocs/release2_0.xmlr2=492832 == --- jakarta/commons/proper/lang/trunk/xdocs/releasenotes2_0.xml (original) +++ jakarta/commons/proper/lang/trunk/xdocs/release2_0.xml Thu Jan 4 16:21:33 2007 @@ -17,15 +17,14 @@ -- document properties - titleUpgrade from 2.0 to 2.1/title + titleRelease notes for 2.0/title author email=commons-dev@jakarta.apache.orgCommons Documentation Team/author /properties body section name=Upgrade p -These are the release notes and advice for upgrading Commons-Lang from -version 2.0 to version 2.1. +These are the release notes and advice for Commons-Lang version 2.0. source INTRODUCTION: Propchange: jakarta/commons/proper/lang/trunk/xdocs/release2_0.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r492833 - in /jakarta/commons/proper/lang/trunk/xdocs: index.xml release2_0.xml releasenotes2_0.xml
Author: scolebourne Date: Thu Jan 4 16:24:00 2007 New Revision: 492833 URL: http://svn.apache.org/viewvc?view=revrev=492833 Log: Remove release2_0.xml as it duplicates upgradeto2_0.xml Removed: jakarta/commons/proper/lang/trunk/xdocs/release2_0.xml jakarta/commons/proper/lang/trunk/xdocs/releasenotes2_0.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/xdocs/index.xml?view=diffrev=492833r1=492832r2=492833 == --- jakarta/commons/proper/lang/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/lang/trunk/xdocs/index.xml Thu Jan 4 16:24:00 2007 @@ -48,11 +48,11 @@ table trthVersion/ththRelease date/ththJavadoc/ththRelease notes/th/tr -trtd2.3/tdtdPending/tdtda href=api-2.3/api-2.3/a/tdtda href=upgradeto2_3.htmlupgrade to 2.3/a/td/tr -trtd2.2/tdtd04/Oct/06/tdtda href=api-2.2/api-2.2/a/tdtda href=upgradeto2_2.htmlupgrade to 2.2/a/td/tr -trtd2.1/tdtd13/Jun/06/tdtda href=api-2.1/api-2.1/a/tdtda href=upgradeto2_1.htmlupgrade to 2.1/a/td/tr -trtd2.0/tdtd02/Sep/03/tdtda href=api-2.0/api-2.0/a/tdtda href=release2_0.htmlrelease notes for 2.0/a/td/tr -trtd1.0.1/tdtd25/Nov/02/tdtda href=api-1.0.1/api-1.0.1/a/tdtda href=http://archive.apache.org/dist/jakarta/commons/lang/old/v1.0.1/RELEASE-NOTES.txt;upgrade to 1.0.1/a/td/tr +trtd2.3/tdtdPending/tdtda href=api-2.3/api-2.3/a/tdtda href=upgradeto2_3.htmlrelease notes 2.3/a/td/tr +trtd2.2/tdtd04/Oct/06/tdtda href=api-2.2/api-2.2/a/tdtda href=upgradeto2_2.htmlrelease notes 2.2/a/td/tr +trtd2.1/tdtd13/Jun/06/tdtda href=api-2.1/api-2.1/a/tdtda href=upgradeto2_1.htmlrelease notes 2.1/a/td/tr +trtd2.0/tdtd02/Sep/03/tdtda href=api-2.0/api-2.0/a/tdtda href=upgradeto2_0.htmlrelease notes for 2.0/a/td/tr +trtd1.0.1/tdtd25/Nov/02/tdtda href=api-1.0.1/api-1.0.1/a/tdtda href=http://archive.apache.org/dist/jakarta/commons/lang/old/v1.0.1/RELEASE-NOTES.txt;release notes for 1.0.1/a/td/tr trtd1.0/tdtd04/Oct/02/tdtda href=api-1.0/api-1.0/a/tdtda href=http://archive.apache.org/dist/jakarta/commons/lang/old/v1.0/RELEASE-NOTES.txt;release notes for 1.0/a/td/tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Collections] Equator interface
Stephen Kestle wrote: If an Equator is determined to be something worthwhile for the next (generic) version of Collections, I can provide interfaces, default implementations tests etc. I certainly think that there are multiple ways to to equals checks. In my day job we compare by ==, equals and id. Done well, this would make a good enhancement in the 'new' collections. BTW, I favour trying to create a 'FlexiMap' map implementation, which has pluggable hashcode/equals/weakReference/softReference/... So, if anyone wants to give that a go feel free! Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Collections] Equator interface (methods)
Stephen Colebourne wrote: Stephen Kestle wrote: If an Equator is determined to be something worthwhile for the next (generic) version of Collections, I can provide interfaces, default implementations tests etc. I certainly think that there are multiple ways to to equals checks. In my day job we compare by ==, equals and id. Done well, this would make a good enhancement in the 'new' collections. Ok - having got some positive feedback, I will go on to the first issue: the Equator interface design. I propose two methods: one for equality checking, and another for hash codes. This ensures that when used, the general contract of Object.equals() and Object.hashCode() are followed in a similar fashion. There is also the problem of naming here - what should the methods be called? We want it to read well, so we'll start by listing the java equals and compare methods. Summary of the rest of the post: I prefer boolean equate() and int hash(). if ( object1.equals(object2) ) if object1 equals object2 then... - pretty simple if ( object1.compareTo(object2) 1 ) if object1 compare to object2 is greater than 1 then... - compared to would make more sense in a sentence, but we favour active tenses, since methods are an instruction on an object. Probably better is to phrase it like: if (object1: compare [yourself] to object2) is greater than 1 then... if ( comparator.compare(object1, object2) 1 ) if (comparator: compare object1 and object2) is greater than 1 then... Getting hash out of the way is easy: hash(). But what's the correct verb for equality? if ( equator.equate(object1, object2) ) if (equator: equate object1 and object2) then... - I prefer this one at the moment if ( equator.equalTo(object1, object2) ) if (equator: is object1 equal to object2) then ... - I have this at the moment, but it requires reshuffling of the sentence. So this post is a bit verbose, but naming is one of the most important tasks of development, and since this is rather foundational... Cheers Stephen (K) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Collections] Equator interface (and FlexiMap)
Stephen Colebourne wrote: BTW, I favour trying to create a 'FlexiMap' map implementation, which has pluggable hashcode/equals/weakReference/softReference/... So, if anyone wants to give that a go feel free! Stephen In my current code, I have an Equator (equalTo()) method, and a HashEquator (extends Equator and adds a hash() method), but now that I've gone and implemented stuff, it comes down to the fact that nothing uses Equator directly, because so many things use hash codes etc, that you're just shooting yourself in the foot later by not following a similar contract to the Object.equals() method. Thus there will only be one plug for hashcode/equals implementation (hopefully just clarifying what you were thinking). What I also was going to say is that you can use an EquatorMap and ReferenceMap to decorate each other, but they're going to extend from different classes, so that's no good. So, are you talking about one Map to rule them all? Sounds convenient. Stephen (not C :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-betwixt has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-betwixt : Commons Betwixt Package - commons-jelly-tags-betwixt : Commons Jelly - db-ddlutils : Easy-to-use component for working with Database Definition (... Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-betwixt-04012007.jar] identifier set to project name -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html Work Name: build_jakarta-commons_commons-betwixt (Type: Build) Work ended in a state of : Failed Elapsed: 37 secs Command Line: java -Djava.awt.headless=true -Dant.build.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-04012007 -Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04012007.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.795 sec [junit] [junit] Testcase: testRoundTripWithSingleMappingFile took 0.587 sec [junit] Running org.apache.commons.betwixt.TestMultipleCollectionMappings [junit] Testsuite: org.apache.commons.betwixt.TestMultipleCollectionMappings [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.792 sec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.792 sec [junit] [junit] Testcase: testOnlyElements took 0.492 sec [junit] Testcase: testOnlyNodes took 0.029 sec [junit] Testcase: testMixed took 0.028 sec [junit] Testcase: testInvalidXML took 0.026 sec [junit] Running org.apache.commons.betwixt.TestOptions [junit] Testsuite: org.apache.commons.betwixt.TestOptions [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.291 sec [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.291 sec [junit] [junit] Testcase: testGetValue took 0.007 sec [junit] Testcase: testGetNames took 0.001 sec [junit] Testcase: testAddOptions took 0.001 sec [junit] Running org.apache.commons.betwixt.TestRSSRoundTrip [junit] Testsuite: org.apache.commons.betwixt.TestRSSRoundTrip [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.549 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.549 sec [junit] [junit] Testcase: testRoundTrip took 1.315 sec [junit] Caused an ERROR [junit] http://my.netscape.com/publish/formats/rss-0.91.dtd [junit] java.io.FileNotFoundException: http://my.netscape.com/publish/formats/rss-0.91.dtd [junit] at
[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-betwixt has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-betwixt : Commons Betwixt Package - commons-jelly-tags-betwixt : Commons Jelly - db-ddlutils : Easy-to-use component for working with Database Definition (... Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-betwixt-04012007.jar] identifier set to project name -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html Work Name: build_jakarta-commons_commons-betwixt (Type: Build) Work ended in a state of : Failed Elapsed: 37 secs Command Line: java -Djava.awt.headless=true -Dant.build.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-04012007 -Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04012007.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.795 sec [junit] [junit] Testcase: testRoundTripWithSingleMappingFile took 0.587 sec [junit] Running org.apache.commons.betwixt.TestMultipleCollectionMappings [junit] Testsuite: org.apache.commons.betwixt.TestMultipleCollectionMappings [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.792 sec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.792 sec [junit] [junit] Testcase: testOnlyElements took 0.492 sec [junit] Testcase: testOnlyNodes took 0.029 sec [junit] Testcase: testMixed took 0.028 sec [junit] Testcase: testInvalidXML took 0.026 sec [junit] Running org.apache.commons.betwixt.TestOptions [junit] Testsuite: org.apache.commons.betwixt.TestOptions [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.291 sec [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.291 sec [junit] [junit] Testcase: testGetValue took 0.007 sec [junit] Testcase: testGetNames took 0.001 sec [junit] Testcase: testAddOptions took 0.001 sec [junit] Running org.apache.commons.betwixt.TestRSSRoundTrip [junit] Testsuite: org.apache.commons.betwixt.TestRSSRoundTrip [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.549 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.549 sec [junit] [junit] Testcase: testRoundTrip took 1.315 sec [junit] Caused an ERROR [junit] http://my.netscape.com/publish/formats/rss-0.91.dtd [junit] java.io.FileNotFoundException: http://my.netscape.com/publish/formats/rss-0.91.dtd [junit] at
svn commit: r492887 - in /jakarta/commons/proper/jxpath/trunk: ./ xdocs/ xdocs/style/ xdocs/stylesheets/
Author: niallp
Date: Thu Jan 4 19:12:43 2007
New Revision: 492887
URL: http://svn.apache.org/viewvc?view=revrev=492887
Log:
Bring JXPath Maven1 build and site/docs up to date with current practicea:
- remove dependency on commons-build
- create checksums
- source distro unpacks to different directory
- correct mail archive links (from eyebrowse)
- include NOTICE.txt in jar file
- add building page
- add improved source repository page
- add improved issue tracking page
Added:
jakarta/commons/proper/jxpath/trunk/xdocs/building.xml (with props)
jakarta/commons/proper/jxpath/trunk/xdocs/cvs-usage.xml (with props)
jakarta/commons/proper/jxpath/trunk/xdocs/issue-tracking.xml (with props)
jakarta/commons/proper/jxpath/trunk/xdocs/style/
jakarta/commons/proper/jxpath/trunk/xdocs/style/project.css (with props)
Removed:
jakarta/commons/proper/jxpath/trunk/xdocs/stylesheets/
Modified:
jakarta/commons/proper/jxpath/trunk/maven.xml
jakarta/commons/proper/jxpath/trunk/project.properties
jakarta/commons/proper/jxpath/trunk/project.xml
jakarta/commons/proper/jxpath/trunk/xdocs/index.xml
jakarta/commons/proper/jxpath/trunk/xdocs/navigation.xml
Modified: jakarta/commons/proper/jxpath/trunk/maven.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/maven.xml?view=diffrev=492887r1=492886r2=492887
==
--- jakarta/commons/proper/jxpath/trunk/maven.xml (original)
+++ jakarta/commons/proper/jxpath/trunk/maven.xml Thu Jan 4 19:12:43 2007
@@ -15,23 +15,80 @@
limitations under the License.
--
project default=java:jar
+ xmlns:ant=jelly:ant
xmlns:j=jelly:core
!-- == --
- !-- START : C O M M O N S - B U I L D --
+ !-- Copy into the binary distribution --
!-- == --
- !-- Required: Look and Feel for documentation within distributions --
- !-- == --
- postGoal name=xdoc:copy-resources
-copy todir=${basedir}/target/docs/style/ failonerror=false
- fileset dir=${basedir}/../commons-build/xdocs/style
- include name='**/*'/
- exclude name='**/CVS/**'/
- /fileset
+ postGoal name=dist:prepare-bin-filesystem
+
+copy todir=${maven.dist.bin.assembly.dir}
+ fileset file='${basedir}/NOTICE.txt'/
+ !-- fileset file=${basedir}/RELEASE-NOTES.txt/ --
/copy
+
/postGoal
+
!-- == --
- !-- END: C O M M O N S - B U I L D --
+ !-- Copy into the source distribution --
!-- == --
+ postGoal name=dist:prepare-src-filesystem
+
+!-- Copy the NOTICE --
+copy todir=${maven.dist.src.assembly.dir}
+ fileset file='${basedir}/NOTICE.txt'/
+ !-- fileset file=${basedir}/RELEASE-NOTES.txt/ --
+ fileset file=${basedir}/build.properties.sample/
+ fileset file=${basedir}/checkstyle.xml/
+ fileset file=${basedir}/checkstyle.properties/
+/copy
+
+!-- Copy xdoc files --
+copy todir=${maven.dist.src.assembly.dir}/xdocs
+ fileset dir=./xdocs/
+/copy
+
+ /postGoal
+
+!-- == --
+!-- Create MD5 Check Sums --
+!-- == --
+postGoal name=dist
+
+ !-- Create a versioned pom --
+ copy file=${basedir}/project.xml
tofile=${maven.dist.dir}/${maven.final.name}.pom/
+
+ !-- create checksum for pom --
+ ant:checksum file=${maven.dist.dir}/${maven.final.name}.pom
property=pom.md5/
+ ant:echo message=${pom.md5} *${maven.final.name}.pom
+ file=${maven.dist.dir}/${maven.final.name}.pom.md5 /
+
+ !-- create checksum for jar --
+ ant:checksum file=${maven.build.dir}/${maven.final.name}.jar
property=jar.md5/
+ ant:echo message=${jar.md5} *${maven.final.name}.jar
+ file=${maven.build.dir}/${maven.final.name}.jar.md5 /
+
+ !-- create checksum for binary zip --
+ ant:checksum file=${maven.dist.dir}/${maven.final.name}.zip
property=zip.md5/
+ ant:echo message=${zip.md5} *${maven.final.name}.zip
+ file=${maven.dist.dir}/${maven.final.name}.zip.md5 /
+
+ !-- create checksum for binary tar.gz --
+ ant:checksum file=${maven.dist.dir}/${maven.final.name}.tar.gz
property=tar.gz.md5/
+ ant:echo message=${tar.gz.md5} *${maven.final.name}.tar.gz
+ file=${maven.dist.dir}/${maven.final.name}.tar.gz.md5 /
+
+
Re: [jxpath] 1.3
On 1/5/07, Stephen Colebourne [EMAIL PROTECTED] wrote: Matt Benson wrote: Can somebody (Henri?) offer advice on what I and/or other members of the (user and/or Apache committer) community might do to get the ball rolling? Some things to think about: - updating the license in each source file to the latest ASF standards - update the xdocs site generation to fit better with other components: -- see http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture -- update home page with documentation/releases/support section -- add cvs-usage.xml, issue-tracking.xml - compare project.xml to other components Henri updated JXPath to bring the source file headers inline with current ASF policy a few weeks ago. I've just updated the JXPath maven1 build to bring it up to date with current commons practices (site should be available to see in a couple of hours after the next sync) http://svn.apache.org/viewvc?view=revrevision=492887 I think the next thing to do is review the outstanding JIRA tickets and assign those that need to be resolved to 1.3 or post 1.3 (I've created versions for both these for JXPath) Niall Generally, take a look at [io] or [lang], compare and update as appropriate. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r492894 - in /jakarta/commons/proper/jxpath/trunk: ./ src/java/org/apache/commons/jxpath/ src/java/org/apache/commons/jxpath/functions/ src/java/org/apache/commons/jxpath/ri/ src/java/org/
Author: niallp Date: Thu Jan 4 19:56:13 2007 New Revision: 492894 URL: http://svn.apache.org/viewvc?view=revrev=492894 Log: Add missing source file headers Modified: jakarta/commons/proper/jxpath/trunk/checkstyle.xml jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/functions/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/axes/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/beans/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/container/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/dom/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/jdom/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/parser/XPath.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/parser/jcc.bat jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/parser/package.html jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/servlet/package.html jakarta/commons/proper/jxpath/trunk/src/test-webapp/JXPathTest.jsp jakarta/commons/proper/jxpath/trunk/src/test-webapp/WEB-INF/web.xml jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/Vendor.xml Modified: jakarta/commons/proper/jxpath/trunk/checkstyle.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/checkstyle.xml?view=diffrev=492894r1=492893r2=492894 == --- jakarta/commons/proper/jxpath/trunk/checkstyle.xml (original) +++ jakarta/commons/proper/jxpath/trunk/checkstyle.xml Thu Jan 4 19:56:13 2007 @@ -1,4 +1,20 @@ ?xml version=1.0? +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- !DOCTYPE module PUBLIC -//Puppy Crawl//DTD Check Configuration 1.1//EN http://www.puppycrawl.com/dtds/configuration_1_1.dtd; Modified: jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/functions/package.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/functions/package.html?view=diffrev=492894r1=492893r2=492894 == --- jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/functions/package.html (original) +++ jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/functions/package.html Thu Jan 4 19:56:13 2007 @@ -1,3 +1,19 @@ +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- body Implementations of Java class-based extension functions. /body Modified: jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/package.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/package.html?view=diffrev=492894r1=492893r2=492894
[jira] Resolved: (JXPATH-72) 1.2 binaries lack javadoc
[ https://issues.apache.org/jira/browse/JXPATH-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved JXPATH-72. --- Resolution: Duplicate Duplicates JXPATH-70 1.2 binaries lack javadoc - Key: JXPATH-72 URL: https://issues.apache.org/jira/browse/JXPATH-72 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Reporter: Henri Yandell The most recent JXPath release (1.2) lacks Javadoc in its binary files at http://archive.apache.org/dist/jakarta/commons/jxpath/binaries/. -- 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: (JXPATH-70) Javadoc missing from distribution
[ https://issues.apache.org/jira/browse/JXPATH-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved JXPATH-70. --- Resolution: Fixed Fix Version/s: 1.3 Assignee: Niall Pemberton Build has now been fixed, will be available in the next release http://svn.apache.org/viewvc?view=revrevision=492887 Javadoc missing from distribution - Key: JXPATH-70 URL: https://issues.apache.org/jira/browse/JXPATH-70 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Reporter: Paul Copeland Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 The javadoc is missing from the 1.2 zip file. Broken links in the user guide and elsewhere in the documentation reference the missing directory at docs/apidocs where the javadoc should be. -- 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: r492897 - /jakarta/commons/proper/jxpath/trunk/xdocs/index.xml
Author: niallp Date: Thu Jan 4 20:22:21 2007 New Revision: 492897 URL: http://svn.apache.org/viewvc?view=revrev=492897 Log: Point to JXPath Downloads page Modified: jakarta/commons/proper/jxpath/trunk/xdocs/index.xml Modified: jakarta/commons/proper/jxpath/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/xdocs/index.xml?view=diffrev=492897r1=492896r2=492897 == --- jakarta/commons/proper/jxpath/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/jxpath/trunk/xdocs/index.xml Thu Jan 4 20:22:21 2007 @@ -87,20 +87,9 @@ /section section name=Releases -ul - li -a href=http://jakarta.apache.org/site/binindex.cgi#commons-jxpath;Version 1.2 (mirror, bin)/a - /li - li -a href=http://jakarta.apache.org/site/sourceindex.cgi#commons-jxpath;Version 1.2 (mirror, source)/a - /li - li -a href=http://archive.apache.org/dist/jakarta/commons/jxpath/old/v1.1/;Version 1.1/a - /li - li -a href=http://archive.apache.org/dist/jakarta/commons/jxpath/old/v1.0/;Version 1.0/a - /li -/ul +pSee the a href=http://jakarta.apache.org/site/downloads/downloads_commons-jxpath.cgi;JXPath Downloads/a + page for current/previous releases. +/p /section /body - 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. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-04012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at
[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. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-04012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at
[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. 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: 11 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-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-04012007.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-04012007.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) [junit] at
[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. 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: 11 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-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-04012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-04012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-04012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-04012007.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-04012007.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) [junit] at
[jira] Commented: (JXPATH-61) [jxpath] Default Namespace not handled correctly
[ https://issues.apache.org/jira/browse/JXPATH-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462404 ] Niall Pemberton commented on JXPATH-61: --- http://svn.apache.org/viewvc?view=revrevision=329468 http://svn.apache.org/viewvc?view=revrevision=329964 [jxpath] Default Namespace not handled correctly Key: JXPATH-61 URL: https://issues.apache.org/jira/browse/JXPATH-61 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.2 Final Environment: Operating System: All Platform: All Reporter: Richard Unger Priority: Minor Fix For: 1.3 JXPath 1.2 does not handle the default namespace correctly. There is no way to set the default namespace on a context, so xpath expressions with unprefixed node-selections do not match the default namespace. Eg: ?xml version=1.0 encoding=iso-8859-1? test xmlns=http://test; child-element / /test This is valid xml, with default namespace 'http://test' If the following xpath expression is used: '/test/childelement', it will not match the child-element element in this xml file. There appears to be no way to use the function JXPathContext.registerNamespace() to associate a default namespace with the context. The programmer is forced to introduce a namespace prefix for JXPath, the xpath expression 'foo:test/foo:child-element' will correctly match the element if JXPathContext.registerNamespace(foo,http://test;) is called first. This is, IMHO, a bug. -- 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: (JXPATH-61) [jxpath] Default Namespace not handled correctly
[ https://issues.apache.org/jira/browse/JXPATH-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-61: -- Fix Version/s: 1.3 [jxpath] Default Namespace not handled correctly Key: JXPATH-61 URL: https://issues.apache.org/jira/browse/JXPATH-61 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.2 Final Environment: Operating System: All Platform: All Reporter: Richard Unger Priority: Minor Fix For: 1.3 JXPath 1.2 does not handle the default namespace correctly. There is no way to set the default namespace on a context, so xpath expressions with unprefixed node-selections do not match the default namespace. Eg: ?xml version=1.0 encoding=iso-8859-1? test xmlns=http://test; child-element / /test This is valid xml, with default namespace 'http://test' If the following xpath expression is used: '/test/childelement', it will not match the child-element element in this xml file. There appears to be no way to use the function JXPathContext.registerNamespace() to associate a default namespace with the context. The programmer is forced to introduce a namespace prefix for JXPath, the xpath expression 'foo:test/foo:child-element' will correctly match the element if JXPathContext.registerNamespace(foo,http://test;) is called first. This is, IMHO, a bug. -- 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: (JXPATH-2) [jxpath] Using JXPath in multiple threads
[
https://issues.apache.org/jira/browse/JXPATH-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated JXPATH-2:
-
Fix Version/s: 1.3
[jxpath] Using JXPath in multiple threads
-
Key: JXPATH-2
URL: https://issues.apache.org/jira/browse/JXPATH-2
Project: Commons JXPath
Issue Type: Bug
Environment: Operating System: All
Platform: All
Reporter: Robert Sax
Fix For: 1.3
I was unable to determine if JXPath was intended to be used concurrently or
not,
but after using it in a server application that runs 100+ threads
concurrently,
I started getting errors (they were rare) that showed the following trace:
java.lang.NullPointerException
at
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getPropertyNames(BeanPropertyPointer.java:72)
at
org.apache.commons.jxpath.ri.model.beans.PropertyIterator.prepareForIndividualProperty(PropertyIterator.java:248)
at
org.apache.commons.jxpath.ri.model.beans.PropertyIterator.setPositionIndividualProperty(PropertyIterator.java:141)
at
org.apache.commons.jxpath.ri.model.beans.PropertyIterator.setPosition(PropertyIterator.java:127)
at
org.apache.commons.jxpath.ri.axes.ChildContext.setPosition(ChildContext.java:106)
at
org.apache.commons.jxpath.ri.axes.ChildContext.nextNode(ChildContext.java:89)
at
org.apache.commons.jxpath.ri.EvalContext.nextSet(EvalContext.java:322)
at
org.apache.commons.jxpath.ri.axes.UnionContext.setPosition(UnionContext.java:55)
at
org.apache.commons.jxpath.ri.axes.NodeSetContext.nextNode(NodeSetContext.java:64)
at
org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:181)
at
org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:114)
at
com.paychex.hrs.ei.conversion.jaxb.InboundProcessor.process(InboundProcessor.java:136)
The code calling has next looks like:
Iterator oIter = m_oIdentifier.iteratePointers(oXCtx);
while (oIter.hasNext())
{
The application has 100 worker threads, each processing the same
message(converted to beans by JAXB), but different instances of it. This error
occurs infrequently - happening only about once every 3 runs (each run
processes
1000 messages). I performed the test on a P4/Windows box, but I believe that
this is independent of os/system.
I believe I have found some of the source code that may be causing this. It
appears that bean info is stored in an internal cache (JXPathIntrospector)
that
all threads would end up using. For this to be thread safe, JXPathIntrospector
needs to be thread safe (which it is even though synchronization is not used),
and JXPathBasicBeanInfo needs to be thread safe (it is not). Basically what is
happening is that inside of JXPathBasicBeanInfo, a couple of procedures build
member variables on demand. However this demand based building is not thread
safe and so a race condition exists between multiple threads that are both
performing the on demand building. Specifically getPropertyDescriptors and
getPropertyDescriptor modify propertyDescriptors and propertyNames in an
unsafe
manner. Either synchronization should be used or the assignment to the member
variable should be performed last (resulting in duplicate effort but thread
safety). Here are the pieces of code I am referring to:
public PropertyDescriptor[] getPropertyDescriptors() {
if (propertyDescriptors == null) {
try {
BeanInfo bi = null;
if (clazz.isInterface()) {
bi = Introspector.getBeanInfo(clazz);
}
else {
bi = Introspector.getBeanInfo(clazz, Object.class);
}
PropertyDescriptor[] pds = bi.getPropertyDescriptors();
propertyDescriptors = new PropertyDescriptor[pds.length];
// At this point, the cache of property descriptors has been cleared possibly
// conflicting with other threads
System.arraycopy(pds, 0, propertyDescriptors, 0, pds.length);
Arrays.sort(propertyDescriptors, new Comparator() {
public int compare(Object left, Object right) {
return ((PropertyDescriptor)
left).getName().compareTo(
((PropertyDescriptor) right).getName());
}
});
}
...
public PropertyDescriptor getPropertyDescriptor(String propertyName) {
if (propertyNames == null) {
PropertyDescriptor[] pds = getPropertyDescriptors();
propertyNames = new String[pds.length];
// At this point the property names has been cleared possibly conflicting with
// other threads
[jira] Updated: (JXPATH-46) [jxpath] NullPointerException
[ https://issues.apache.org/jira/browse/JXPATH-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-46: -- Fix Version/s: 1.3 [jxpath] NullPointerException - Key: JXPATH-46 URL: https://issues.apache.org/jira/browse/JXPATH-46 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: Linux Platform: PC Reporter: Chris Picton Fix For: 1.3 Attachments: instance.xml, test.java Using the following xpath, I get a NullPointerException, when trying to do a getPointer(): //[EMAIL PROTECTED]'1'][last()] My code and instance data are attached -- 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: (JXPATH-17) JXPathContext.iteratePointers(//*) results are incorrect
[ https://issues.apache.org/jira/browse/JXPATH-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-17: -- Fix Version/s: 1.3 Fixed: http://svn.apache.org/viewvc?view=revrevision=329518 JXPathContext.iteratePointers(//*) results are incorrect -- Key: JXPATH-17 URL: https://issues.apache.org/jira/browse/JXPATH-17 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: Linux Platform: Other Reporter: Boris Ekelchik Fix For: 1.3 Attachments: TryJXPath.java Sometimes strange strings, such as bytes[1] and valid, etc. appear in resulting Pointer.asPath() output instead of the actual data. Please run the main of the attached class to see what I mean. Thanks. -- 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: (JXPATH-5) [jxpath] asPath() returns a path to the last sibling
[
https://issues.apache.org/jira/browse/JXPATH-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated JXPATH-5:
-
Fix Version/s: 1.3
[jxpath] asPath() returns a path to the last sibling
Key: JXPATH-5
URL: https://issues.apache.org/jira/browse/JXPATH-5
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: All
Platform: All
Reporter: Krishna Patil
Fix For: 1.3
The method call JXPathContext::iteratePointers() returns the correct number
of
pointers. However, the pointers do not always return correct path on asPath()
method call on them. A pointer returns a path that corresponds to the last
Node in the sibling Nodes of the node that the pointer points to.
Here is an example:
Class A{
private List list;
//getter and setter
:
}
Here is a code snippet for creating an object graph that starts from
instance of A.
A a1 = new A();
List list1 = new LinkedList();
A a11 = new A();
list1.add(a11);
A a12 = new A();
List list12 = new LinkedList();
A a121 = new A();
list12.add(a121);
a12.setList(list12);
list1.add(a12);
A a13 = new A();
list1.add(a11);
a1.setList(list1);
And the list attribute can have instances of A as elements in it.
The JXPathContext correspong to a1 returns pointers when it's iteratePointers
() method is called. And the pointers correspond to the following nodes.
A[1]
A[2]
A[2]/A[1]
A[3]
This is absolutely as expected. However, asPath() method on each of these
Pointers do not always return the correct path.
Currently, the asPath() method calls on the corresponding Pointers return
this
output respectively.
A[3]
A[3]
A[2]/A[1]
A[3]
This needs to be fixed.
--
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: r492910 - /jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java
Author: bayard
Date: Thu Jan 4 21:30:04 2007
New Revision: 492910
URL: http://svn.apache.org/viewvc?view=revrev=492910
Log:
Adding test for LANG-312. It passes for me, so I'm interested in whether it
fails for anybody else.
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java?view=diffrev=492910r1=492909r2=492910
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java
Thu Jan 4 21:30:04 2007
@@ -19,6 +19,7 @@
import java.lang.reflect.Constructor;
import java.lang.reflect.Modifier;
import java.util.Calendar;
+import java.util.Date;
import java.util.Locale;
import java.util.TimeZone;
@@ -209,6 +210,19 @@
DateFormatUtils.SMTP_DATETIME_FORMAT.getPattern(),
DateFormatUtils.SMTP_DATETIME_FORMAT.getLocale());
assertEquals(Sun, 08 Jun 2003 13:11:12 +, text);
+}
+
+public void testLang312() {
+String pattern = dd/MM/;
+TimeZone timeZone = TimeZone.getTimeZone(CET);
+Locale locale = Locale.GERMANY;
+
+Calendar cal = Calendar.getInstance(timeZone, locale);
+cal.set(1948, 3, 19);
+assertEquals(19/04/1948, DateFormatUtils.format( cal.getTime(),
pattern, timeZone, locale ) );
+
+Date date = new Date(48, 3, 19);
+assertEquals(19/04/1948, DateFormatUtils.format( date, pattern,
timeZone, locale ) );
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r492913 - /jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java
Author: bayard Date: Thu Jan 4 21:36:50 2007 New Revision: 492913 URL: http://svn.apache.org/viewvc?view=revrev=492913 Log: Also test the JDK Modified: jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java Modified: jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java?view=diffrev=492913r1=492912r2=492913 == --- jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java (original) +++ jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/DateFormatUtilsTest.java Thu Jan 4 21:36:50 2007 @@ -217,11 +217,19 @@ TimeZone timeZone = TimeZone.getTimeZone(CET); Locale locale = Locale.GERMANY; +// show Calendar is good Calendar cal = Calendar.getInstance(timeZone, locale); cal.set(1948, 3, 19); assertEquals(19/04/1948, DateFormatUtils.format( cal.getTime(), pattern, timeZone, locale ) ); Date date = new Date(48, 3, 19); + +// test JDK +java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat(pattern, locale); +sdf.setTimeZone(timeZone); +assertEquals(19/04/1948, sdf.format( date ) ); + +// test Commons assertEquals(19/04/1948, DateFormatUtils.format( date, pattern, timeZone, locale ) ); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462406
]
Henri Yandell commented on LANG-312:
Thanks for the report Hayo.
I've made a unit test, but it passes (under JDK 1.4 and 1.5; but on OS X).
***
public void testLang312() {
String pattern = dd/MM/;
TimeZone timeZone = TimeZone.getTimeZone(CET);
Locale locale = Locale.GERMANY;
// show Calendar is good
Calendar cal = Calendar.getInstance(timeZone, locale);
cal.set(1948, 3, 19);
assertEquals(19/04/1948, DateFormatUtils.format( cal.getTime(),
pattern, timeZone, locale ) );
Date date = new Date(48, 3, 19);
// test JDK
java.text.SimpleDateFormat sdf = new
java.text.SimpleDateFormat(pattern, locale);
sdf.setTimeZone(timeZone);
assertEquals(19/04/1948, sdf.format( date ) );
// test Commons
assertEquals(19/04/1948, DateFormatUtils.format( date, pattern,
timeZone, locale ) );
}
***
Does that look right to you, and more importantly does it fail on your machine?
It's checked in - so the nightly build (Linux + JDK 1.5) will hit it too.
DateFormatUtils sits on top of FastDateFormat, but there's not a huge amount in
there so I'm quite interested in whether the same issue exists in
java.text.SimpleDateFormat.
We've a release heading out soon (one other blocker issue besides this one), so
hopefully we can get to the bottom of this quickly and get the
deprecations/javadoc warnings out there quickly if need be.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462407
]
Henri Yandell commented on LANG-312:
(copying you with the quick reply to oneself :) )
The only difference I know of between a new Date and a Calendar.getDate is that
the latter has the TimeZone from the Calendar. So this might imply that the
TimeZone being passed in is not correctly used somewhere.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET
[jira] Commented: (JXPATH-12) [jxpath] Descendant or self axis does not work correctly at root node
[ https://issues.apache.org/jira/browse/JXPATH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462419 ] Simon Raess commented on JXPATH-12: --- I've just applied your patch to version 1.2. The reported problem is solved now. [jxpath] Descendant or self axis does not work correctly at root node - Key: JXPATH-12 URL: https://issues.apache.org/jira/browse/JXPATH-12 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: other Platform: Other Reporter: Simon Raess Attachments: DescendantOrSelfTest.java, patch.jxpath-12.txt Given the following XML document: root id=1234/ and the XPath: //root/@id/text(). JXPath returns null instead of 1234. JXPathContext context = JXPathContext.newContext(doc); assertEquals(value, context.selectSingleNode(//root/@id/text())); The attached JUnit test highlights the problem. It seems that JXPath does not find the root node if it is accessed with the axis descendant-or-self. -- 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
+1 Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: 1. Make various changes to the sandbox-parent, which is currently located in sandbox-trunk: - Remove local style rules - Remove stuff that is inherited from commons-parent, most notably maven-classic-skin 2. Change pom.xml and site.xml for many sandbox components - Make sure inheritance is correct - Align navigation structure - Remove stuff that is inherited from sandbox-parent 3. Re-publish the sites for all sandbox components - Do mvn site:deploy for all sandbox components - Would like to move sandbox-parent to its own directory in SVN - If we feel that it's necessary at this time: release commons-skin, commons-parent and sandbox-parent Does this sound OK to you? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
