Re: [VOTE] Lang 2.3 RC1
Rahul Akolkar wrote: On 2/2/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/1/07, Henri Yandell [EMAIL PROTECTED] wrote: What do people think - update PROPOSALs or delete them? Neither - leave it unchanged. It is historical and I think it is obvious it is, many (most?) components have them and I've never seen it raised as a cause for confusion. snap/ Archival is good, I read proposals. But from trunk. One way to avoid potential confusion is to not make it part of the distros, if indeed it is added there. I think the proposal should no longer be part of the website or distro, but left unchanged in SVN. There may be a case for an updated scope doc on the website (ie. a new xdoc). Stephen - 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 82 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-03022007.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 2303022007, vmgump.apache.org:vmgump-public:2303022007 Gump E-mail Identifier (unique within run) #39. -- 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 82 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-03022007.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 2303022007, vmgump.apache.org:vmgump-public:2303022007 Gump E-mail Identifier (unique within run) #39. -- 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 82 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-03022007.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 2303022007, vmgump.apache.org:vmgump-public:2303022007 Gump E-mail Identifier (unique within run) #42. -- 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 82 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-03022007.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 2303022007, vmgump.apache.org:vmgump-public:2303022007 Gump E-mail Identifier (unique within run) #42. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r503227 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/ConfigurationUtils.java src/test/org/apache/commons/configuration/TestConfigurationUtils
Author: oheger
Date: Sat Feb 3 08:19:15 2007
New Revision: 503227
URL: http://svn.apache.org/viewvc?view=revrev=503227
Log:
CONFIGURATION-252: ConfigurationUtils.getFile() now always checks first whether
the passed in file name is absolute.
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationUtils.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationUtils.java?view=diffrev=503227r1=503226r2=503227
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationUtils.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationUtils.java
Sat Feb 3 08:19:15 2007
@@ -595,7 +595,22 @@
* Tries to convert the specified base path and file name into a file
object.
* This method is called e.g. by the save() methods of file based
* configurations. The parameter strings can be relative files, absolute
- * files and URLs as well.
+ * files and URLs as well. This implementation checks first whether the
passed in
+ * file name is absolute. If this is the case, it is returned. Otherwise
+ * further checks are performed whether the base path and file name can be
+ * combined to a valid URL or a valid file name. emNote:/em The test
+ * if the passed in file name is absolute is performed using
+ * codejava.io.File.isAbsolute()/code. If the file name starts with a
+ * slash, this method will return btrue/b on Unix, but bfalse/b on
+ * Windows. So to ensure correct behavior for relative file names on all
+ * platforms you should never let relative paths start with a slash. E.g.
+ * in a configuration definition file do not use something like that:
+ * pre
+ * lt;properties fileName=/subdir/my.properties/gt;
+ * /pre
+ * Under Windows this path would be resolved relative to the configuration
+ * definition file. Under Unix this would be treated as an absolute path
+ * name.
*
* @param basePath the base path
* @param fileName the file name
@@ -603,6 +618,13 @@
*/
public static File getFile(String basePath, String fileName)
{
+// Check if the file name is absolute
+File f = new File(fileName);
+if (f.isAbsolute())
+{
+return f;
+}
+
// Check if URLs are involved
URL url;
try
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java?view=diffrev=503227r1=503226r2=503227
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
Sat Feb 3 08:19:15 2007
@@ -175,7 +175,7 @@
expected.add(value2);
ListAssert.assertEquals('key2' property, expected,
conf2.getList(key2));
}
-
+
public void testGetFile() throws Exception
{
File directory = new File(target);
@@ -186,6 +186,9 @@
assertEquals(reference,
ConfigurationUtils.getFile(directory.getAbsolutePath(), reference.getName()));
assertEquals(reference,
ConfigurationUtils.getFile(directory.toURL().toString(), reference.getName()));
assertEquals(reference, ConfigurationUtils.getFile(invalid,
reference.toURL().toString()));
+assertEquals(reference, ConfigurationUtils.getFile(
+jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties,
+reference.getAbsolutePath()));
}
public void testLocateWithNullTCCL() throws Exception
Modified: jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/xdocs/changes.xml?view=diffrev=503227r1=503226r2=503227
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml Sat Feb 3
08:19:15 2007
@@ -26,6 +26,12 @@
action dev=oheger type=add
A pom for maven 2 was added.
[jira] Resolved: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file
[ https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-252. Resolution: Fixed Fix Version/s: 1.4 The getFile() method now checks first whether an absolute file name is passed in. A note about the behavior of File.isAbsolute() on Windows and Unix was also added to the Javadocs. Detection of absolute fileNames when configuration sources are defined in a JAR file Key: CONFIGURATION-252 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Linux Reporter: Heiko Seebach Assigned To: Oliver Heger Fix For: 1.4 Attachments: support-for-jar-protocol.patch.txt When using several configuration sources, the sources are defined in a an xml attribute like fileName=usergui.properties The method org.apache.commons.configuration.ConfigurationUtils.getFile(String basePath, String fileName) converts the basePath and fileName into a File. The JavaDoc says: The parameter strings can be relative files, absolute files and URLs as well. The file containing the definition of the configuration sources will become the basePath of this method. After a log of debugging I found, that if the basePath start with jar: the method assumes that the fileName is relative, evene if it's absolute. This happens, because there's a ProtocolHandler for Jar files and jar: is a valid protocol. So the statement new URL(new URL(basePath), fileName) doesn't throw a MalformedUrlException. Since the URL is valid, it's never checked, if the fileName may be absolute. Attention: this is only the case on Unix/Linux, since this is a valid URL jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties while under Windows, a MalformedUrlException will be thrown, when the fileName is absolute: jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties I attached a patch that checks, whether the URL protocol is jar and the fileName is absolute. If so, the absolute file will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 25 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-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-03022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-03022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 25 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-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-03022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-03022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 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-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-03022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-03022007.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-03022007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 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-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-03022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-03022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-03022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-03022007.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-03022007.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)
Re: [all] exceptions and localization
On 1/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I'm late to the table on this thread, and only care about the Commons libraries I care about :-) Thanks for your interest in this thread. but you should be aware that this attitude will disqualify the use of such libraries from use within code from organizations that have strict rules about implementing localization. I work for such an organization (Sun) ... the key rules are that any message that might be visible to users *must* be localizable. I agree with you and thought localization should be provided by the layer which provides the message. Other people think this should be done at application level, if done at all. For log messages, that tends to translate into a straightforward policy that DEBUG and TRACE type messages do not need to be localized, but anything from INFO level above must be. The issue for exception messages is a bit more interesting. How does the library developer know whether or not the message part of the exception will be displayed to end users? From a pragmatic viewpoint, you can pretty much assume this will happen with exceptions in webapps, while many Swing apps will hide that sort of stuff to some degree. I think that since low level components may be used almost anywhere, their messages *may* be displayed and this sole possibility is enough to justify a localized version should be made available. If the application gets an error it really doesn't know about, it can simply display it. But, as a bottom line, if I'm interested in maximum adoption of a Commons library I work on, I will diligently ensure that exception messages are localizable :-). When I first started this long thread, I thought the need for localized error messages as provided by exceptions was acknowledged by everyone and asked for the way to implement it, starting from a simple one which already works. I was wrong. The disagreement started about the need itself and slipped to the level at which implementation should be done. I would really like to reach a compromise on this issue, something that could by accepted by everybody. I don't want to get banned with a -1 on a commit, but at least a few people would like localized error messages that can be simply forwarded upward from lower layers to upper layer for display without processing. Standard java already provides Throwable.getLocalizedMessage() since JDK 1.1. I could set up for [math] only an exception hierarchy that only add a few constructors and an implementation of this method without any change in the Throwable.getMessage() behaviour. Does this sound reasonable ? Sorry I was out of pocket this week and could not reiterate my personal +1 for moving forward as you suggest, Luc. I will add a few of more comments below. If anyone still has serious reservations - especially those who now or in the future may contribute to [math] - pls speak up; otherwise we can move on. Thanks to all who provided comments. 1) My initial +1 was based on the fact that the error management that you need to support this approach is in fact there in Mantissa and if you *don't* support localization when text is being generated, you either need to get into nonsense like parsing and translating error messages, complicating your exceptions hierarchy, or losing/hiding information at higher levels. If you do the work to localize when the string is generated, that gives a choice at higher levels, which to me is goodness (assuming you are prepared to do the work and the implementation is robust against missing bundles, etc.). 2) Commons math generates error messages now, and should generate better messages (as Mantissa does) in the future that using applications may want to display to end users or in application logs. I would like for those messages to be localizable. If one of our solvers does not converge because initial values do not bracket a root, for example, I would like the developer of a localized client application that uses the solver to be able to display that message directly in a log or to the user. Whether or not logging is good or bad is completely irrelevant to this discussion. 3) Apache is a do-ocracy and we have a proposal before us to significantly improve exception management and error reporting in [math] by extending and leveraging the framework in Mantissa. Luc is volunteering to do this and the only other active contributor to [math] who has chimed in (yours truly) is also in favor. The arguments against are either it is too much work to implement exception error message localization or it may not be robust. Luc is stepping up to *do* the work (actually, leverage work already mostly done in Mantissa) and I don't see robustness or performance risk in what he has implemented. Pls speak up if I am missing something in the latter case. Therefore, appreciating the feedback from others and reservations about applying across commons, for
Re: [all] exceptions and localization
So, nobody liked my idea of just providing the data?
On 1/30/07, James Carman [EMAIL PROTECTED] wrote:
How about if we give the data for the localized message instead of
localizing it ourselves? I've done this for a class I call
BusinessLogicException (used for when a user breaks a business rule
like already a user with that name in the system since you would
want to display that error message to the user). What I did was
create a message class like this:
public class BusinessLogicException extends Exception
{
private final String messageKey;
private final Object[] arguments; // May have been called parameters?
// Constructors and getters here...
}
So, if an application wants to localize the message, they can use
their own localization paradigm (i18n, resource bundles, Tapestry
messages, etc.).
On 1/30/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/28/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
I am interested in what others have to
say about this as a general practice for commons. For [math]
specifically,
I think it is important that we can fit seamlessly into localized
applications, and we are refactoring our exceptions hierarchy anyway, so
I
say go for it.
I disagree strongly with the whole concept of localized exception
messages. Localization for users yes, but developers no.
On 1/28/07, Luc Maisonobe [EMAIL PROTECTED] wrote:
As a non-native english speaker, I am quite eager to provide users
with libraries that can be embedded seemlessly into localized
applications.
IMO, a localized application actually means localization for users, and
implies nothing for developers.
Adding localized error messages is another place for the application to
go wrong, so you're going to have to test this fully. After all, if you
get it wrong, you could lose the real exception and just get a
meaningless failed to localize exception. And thats a terrible outcome.
For the record, I would -1 any code commit to add localized error
messages to a component I actively commit to.
I'm late to the table on this thread, and only care about the Commons
libraries I care about :-), but you should be aware that this attitude will
disqualify the use of such libraries from use within code from organizations
that have strict rules about implementing localization. I work for such an
organization (Sun) ... the key rules are that any message that might be
visible to users *must* be localizable.
For log messages, that tends to translate into a straightforward policy that
DEBUG and TRACE type messages do not need to be localized, but anything from
INFO level above must be. The issue for exception messages is a bit more
interesting. How does the library developer know whether or not the message
part of the exception will be displayed to end users? From a pragmatic
viewpoint, you can pretty much assume this will happen with exceptions in
webapps, while many Swing apps will hide that sort of stuff to some degree.
But, as a bottom line, if I'm interested in maximum adoption of a Commons
library I work on, I will diligently ensure that exception messages are
localizable :-).
Stephen
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I'm late to the table on this thread, and only care about the Commons libraries I care about :-) Thanks for your interest in this thread. but you should be aware that this attitude will disqualify the use of such libraries from use within code from organizations that have strict rules about implementing localization. I work for such an organization (Sun) ... the key rules are that any message that might be visible to users *must* be localizable. I agree with you and thought localization should be provided by the layer which provides the message. Other people think this should be done at application level, if done at all. For log messages, that tends to translate into a straightforward policy that DEBUG and TRACE type messages do not need to be localized, but anything from INFO level above must be. The issue for exception messages is a bit more interesting. How does the library developer know whether or not the message part of the exception will be displayed to end users? From a pragmatic viewpoint, you can pretty much assume this will happen with exceptions in webapps, while many Swing apps will hide that sort of stuff to some degree. I think that since low level components may be used almost anywhere, their messages *may* be displayed and this sole possibility is enough to justify a localized version should be made available. If the application gets an error it really doesn't know about, it can simply display it. But, as a bottom line, if I'm interested in maximum adoption of a Commons library I work on, I will diligently ensure that exception messages are localizable :-). When I first started this long thread, I thought the need for localized error messages as provided by exceptions was acknowledged by everyone and asked for the way to implement it, starting from a simple one which already works. I was wrong. The disagreement started about the need itself and slipped to the level at which implementation should be done. I would really like to reach a compromise on this issue, something that could by accepted by everybody. I don't want to get banned with a -1 on a commit, but at least a few people would like localized error messages that can be simply forwarded upward from lower layers to upper layer for display without processing. Standard java already provides Throwable.getLocalizedMessage() since JDK 1.1. I could set up for [math] only an exception hierarchy that only add a few constructors and an implementation of this method without any change in the Throwable.getMessage() behaviour. Does this sound reasonable ? Sorry I was out of pocket this week and could not reiterate my personal +1 for moving forward as you suggest, Luc. I will add a few of more comments below. If anyone still has serious reservations - especially those who now or in the future may contribute to [math] - pls speak up; otherwise we can move on. Thanks to all who provided comments. 1) My initial +1 was based on the fact that the error management that you need to support this approach is in fact there in Mantissa and if you *don't* support localization when text is being generated, you either need to get into nonsense like parsing and translating error messages, complicating your exceptions hierarchy, or losing/hiding information at higher levels. If you do the work to localize when the string is generated, that gives a choice at higher levels, which to me is goodness (assuming you are prepared to do the work and the implementation is robust against missing bundles, etc.). 2) Commons math generates error messages now, and should generate better messages (as Mantissa does) in the future that using applications may want to display to end users or in application logs. I would like for those messages to be localizable. If one of our solvers does not converge because initial values do not bracket a root, for example, I would like the developer of a localized client application that uses the solver to be able to display that message directly in a log or to the user. Whether or not logging is good or bad is completely irrelevant to this discussion. 3) Apache is a do-ocracy and we have a proposal before us to significantly improve exception management and error reporting in [math] by extending and leveraging the framework in Mantissa. Luc is volunteering to do this and the only other active contributor to [math] who has chimed in (yours truly) is also in favor. The arguments against are either it is too much work to implement exception error message localization or it may not be robust. Luc is stepping up to *do* the work (actually, leverage work already mostly done in Mantissa) and I don't see robustness or performance risk in what he has implemented. Pls speak up if I am missing something in the
Re: [all] exceptions and localization
Well, I wouldn't even provide a getMessage(Locale). I'd leave it up to the running application to resolve the message. For instance, in Tapestry, it doesn't use resource bundles to localize messages, at least not directly in application code. It uses a special Messages object. So, I would provide getKey()/getParameters() methods only and leave it up to the containing application to localize the text. That way, they can give some context to the error message instead of relying upon us to be general enough. On 2/3/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I'm late to the table on this thread, and only care about the Commons libraries I care about :-) Thanks for your interest in this thread. but you should be aware that this attitude will disqualify the use of such libraries from use within code from organizations that have strict rules about implementing localization. I work for such an organization (Sun) ... the key rules are that any message that might be visible to users *must* be localizable. I agree with you and thought localization should be provided by the layer which provides the message. Other people think this should be done at application level, if done at all. For log messages, that tends to translate into a straightforward policy that DEBUG and TRACE type messages do not need to be localized, but anything from INFO level above must be. The issue for exception messages is a bit more interesting. How does the library developer know whether or not the message part of the exception will be displayed to end users? From a pragmatic viewpoint, you can pretty much assume this will happen with exceptions in webapps, while many Swing apps will hide that sort of stuff to some degree. I think that since low level components may be used almost anywhere, their messages *may* be displayed and this sole possibility is enough to justify a localized version should be made available. If the application gets an error it really doesn't know about, it can simply display it. But, as a bottom line, if I'm interested in maximum adoption of a Commons library I work on, I will diligently ensure that exception messages are localizable :-). When I first started this long thread, I thought the need for localized error messages as provided by exceptions was acknowledged by everyone and asked for the way to implement it, starting from a simple one which already works. I was wrong. The disagreement started about the need itself and slipped to the level at which implementation should be done. I would really like to reach a compromise on this issue, something that could by accepted by everybody. I don't want to get banned with a -1 on a commit, but at least a few people would like localized error messages that can be simply forwarded upward from lower layers to upper layer for display without processing. Standard java already provides Throwable.getLocalizedMessage() since JDK 1.1. I could set up for [math] only an exception hierarchy that only add a few constructors and an implementation of this method without any change in the Throwable.getMessage() behaviour. Does this sound reasonable ? Sorry I was out of pocket this week and could not reiterate my personal +1 for moving forward as you suggest, Luc. I will add a few of more comments below. If anyone still has serious reservations - especially those who now or in the future may contribute to [math] - pls speak up; otherwise we can move on. Thanks to all who provided comments. 1) My initial +1 was based on the fact that the error management that you need to support this approach is in fact there in Mantissa and if you *don't* support localization when text is being generated, you either need to get into nonsense like parsing and translating error messages, complicating your exceptions hierarchy, or losing/hiding information at higher levels. If you do the work to localize when the string is generated, that gives a choice at higher levels, which to me is goodness (assuming you are prepared to do the work and the implementation is robust against missing bundles, etc.). 2) Commons math generates error messages now, and should generate better messages (as Mantissa does) in the future that using applications may want to display to end users or in application logs. I would like for those messages to be localizable. If one of our solvers does not converge because initial values do not bracket a root, for example, I would like the developer of a localized client application that uses the solver to be able to display that message directly in a log or to the user. Whether or not logging is good or bad is completely irrelevant to this discussion. 3)
Re: [all] exceptions and localization
On 2/3/07, James Carman [EMAIL PROTECTED] wrote: Well, I wouldn't even provide a getMessage(Locale). I'd leave it up to the running application to resolve the message. For instance, in Tapestry, it doesn't use resource bundles to localize messages, at least not directly in application code. It uses a special Messages object. So, I would provide getKey()/getParameters() methods only and leave it up to the containing application to localize the text. That way, they can give some context to the error message instead of relying upon us to be general enough. The problem with that is that generic handlers that display messages would not work. I like the idea of carrying the data along, though and exposing it, as well as providing translate (see http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup ) and getMessage(Locale) methods. That gives client apps the most flexibility. What do you think, Luc? Phil On 2/3/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I'm late to the table on this thread, and only care about the Commons libraries I care about :-) Thanks for your interest in this thread. but you should be aware that this attitude will disqualify the use of such libraries from use within code from organizations that have strict rules about implementing localization. I work for such an organization (Sun) ... the key rules are that any message that might be visible to users *must* be localizable. I agree with you and thought localization should be provided by the layer which provides the message. Other people think this should be done at application level, if done at all. For log messages, that tends to translate into a straightforward policy that DEBUG and TRACE type messages do not need to be localized, but anything from INFO level above must be. The issue for exception messages is a bit more interesting. How does the library developer know whether or not the message part of the exception will be displayed to end users? From a pragmatic viewpoint, you can pretty much assume this will happen with exceptions in webapps, while many Swing apps will hide that sort of stuff to some degree. I think that since low level components may be used almost anywhere, their messages *may* be displayed and this sole possibility is enough to justify a localized version should be made available. If the application gets an error it really doesn't know about, it can simply display it. But, as a bottom line, if I'm interested in maximum adoption of a Commons library I work on, I will diligently ensure that exception messages are localizable :-). When I first started this long thread, I thought the need for localized error messages as provided by exceptions was acknowledged by everyone and asked for the way to implement it, starting from a simple one which already works. I was wrong. The disagreement started about the need itself and slipped to the level at which implementation should be done. I would really like to reach a compromise on this issue, something that could by accepted by everybody. I don't want to get banned with a -1 on a commit, but at least a few people would like localized error messages that can be simply forwarded upward from lower layers to upper layer for display without processing. Standard java already provides Throwable.getLocalizedMessage() since JDK 1.1. I could set up for [math] only an exception hierarchy that only add a few constructors and an implementation of this method without any change in the Throwable.getMessage() behaviour. Does this sound reasonable ? Sorry I was out of pocket this week and could not reiterate my personal +1 for moving forward as you suggest, Luc. I will add a few of more comments below. If anyone still has serious reservations - especially those who now or in the future may contribute to [math] - pls speak up; otherwise we can move on. Thanks to all who provided comments. 1) My initial +1 was based on the fact that the error management that you need to support this approach is in fact there in Mantissa and if you *don't* support localization when text is being generated, you either need to get into nonsense like parsing and translating error messages, complicating your exceptions hierarchy, or losing/hiding information at higher levels. If you do the work to localize when the string is generated, that gives a choice at higher levels, which to me is goodness (assuming you are prepared to do the work and the implementation is robust against missing bundles, etc.). 2) Commons
Re: [all] exceptions and localization
How does a calling application override the message, if they wish? On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 2/3/07, James Carman [EMAIL PROTECTED] wrote: Well, I wouldn't even provide a getMessage(Locale). I'd leave it up to the running application to resolve the message. For instance, in Tapestry, it doesn't use resource bundles to localize messages, at least not directly in application code. It uses a special Messages object. So, I would provide getKey()/getParameters() methods only and leave it up to the containing application to localize the text. That way, they can give some context to the error message instead of relying upon us to be general enough. The problem with that is that generic handlers that display messages would not work. I like the idea of carrying the data along, though and exposing it, as well as providing translate (see http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup ) and getMessage(Locale) methods. That gives client apps the most flexibility. What do you think, Luc? Phil On 2/3/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I'm late to the table on this thread, and only care about the Commons libraries I care about :-) Thanks for your interest in this thread. but you should be aware that this attitude will disqualify the use of such libraries from use within code from organizations that have strict rules about implementing localization. I work for such an organization (Sun) ... the key rules are that any message that might be visible to users *must* be localizable. I agree with you and thought localization should be provided by the layer which provides the message. Other people think this should be done at application level, if done at all. For log messages, that tends to translate into a straightforward policy that DEBUG and TRACE type messages do not need to be localized, but anything from INFO level above must be. The issue for exception messages is a bit more interesting. How does the library developer know whether or not the message part of the exception will be displayed to end users? From a pragmatic viewpoint, you can pretty much assume this will happen with exceptions in webapps, while many Swing apps will hide that sort of stuff to some degree. I think that since low level components may be used almost anywhere, their messages *may* be displayed and this sole possibility is enough to justify a localized version should be made available. If the application gets an error it really doesn't know about, it can simply display it. But, as a bottom line, if I'm interested in maximum adoption of a Commons library I work on, I will diligently ensure that exception messages are localizable :-). When I first started this long thread, I thought the need for localized error messages as provided by exceptions was acknowledged by everyone and asked for the way to implement it, starting from a simple one which already works. I was wrong. The disagreement started about the need itself and slipped to the level at which implementation should be done. I would really like to reach a compromise on this issue, something that could by accepted by everybody. I don't want to get banned with a -1 on a commit, but at least a few people would like localized error messages that can be simply forwarded upward from lower layers to upper layer for display without processing. Standard java already provides Throwable.getLocalizedMessage() since JDK 1.1. I could set up for [math] only an exception hierarchy that only add a few constructors and an implementation of this method without any change in the Throwable.getMessage() behaviour. Does this sound reasonable ? Sorry I was out of pocket this week and could not reiterate my personal +1 for moving forward as you suggest, Luc. I will add a few of more comments below. If anyone still has serious reservations - especially those who now or in the future may contribute to [math] - pls speak up; otherwise we can move on. Thanks to all who provided comments. 1) My initial +1 was based on the fact that the error management that you need to support this approach is in fact there in Mantissa and if you *don't* support localization when text is being generated, you either need to get into nonsense like parsing and translating error messages, complicating your exceptions hierarchy, or losing/hiding information at higher levels. If you do
Re: [all] exceptions and localization
On 2/3/07, James Carman [EMAIL PROTECTED] wrote: How does a calling application override the message, if they wish? They could subclass and override translate() or, assuming we take your suggestion and carry the data along, they could access the data and do whatever they want with it. I agree that it is a good idea to persist and expose the key and parts. I just also think it is good for getMessage() and getMessage(Locale) to provide default localization out of the box. Phil
Re: [all] exceptions and localization
Why not getMessage(ResourceBundle) so that the client apps can use their own resource bundle if they wish? Or, provide a common interface and adaptors that adapt different i18n mechanisms to your paradigm. So, you'd have: String getMessage( MessageSource src ); And, you'd have different flavors of MessageSource, one for ResourceBundles, one for HiveMind messages, one for commons i18n, etc. On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 2/3/07, James Carman [EMAIL PROTECTED] wrote: Well, I wouldn't even provide a getMessage(Locale). I'd leave it up to the running application to resolve the message. For instance, in Tapestry, it doesn't use resource bundles to localize messages, at least not directly in application code. It uses a special Messages object. So, I would provide getKey()/getParameters() methods only and leave it up to the containing application to localize the text. That way, they can give some context to the error message instead of relying upon us to be general enough. The problem with that is that generic handlers that display messages would not work. I like the idea of carrying the data along, though and exposing it, as well as providing translate (see http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup ) and getMessage(Locale) methods. That gives client apps the most flexibility. What do you think, Luc? Phil On 2/3/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I'm late to the table on this thread, and only care about the Commons libraries I care about :-) Thanks for your interest in this thread. but you should be aware that this attitude will disqualify the use of such libraries from use within code from organizations that have strict rules about implementing localization. I work for such an organization (Sun) ... the key rules are that any message that might be visible to users *must* be localizable. I agree with you and thought localization should be provided by the layer which provides the message. Other people think this should be done at application level, if done at all. For log messages, that tends to translate into a straightforward policy that DEBUG and TRACE type messages do not need to be localized, but anything from INFO level above must be. The issue for exception messages is a bit more interesting. How does the library developer know whether or not the message part of the exception will be displayed to end users? From a pragmatic viewpoint, you can pretty much assume this will happen with exceptions in webapps, while many Swing apps will hide that sort of stuff to some degree. I think that since low level components may be used almost anywhere, their messages *may* be displayed and this sole possibility is enough to justify a localized version should be made available. If the application gets an error it really doesn't know about, it can simply display it. But, as a bottom line, if I'm interested in maximum adoption of a Commons library I work on, I will diligently ensure that exception messages are localizable :-). When I first started this long thread, I thought the need for localized error messages as provided by exceptions was acknowledged by everyone and asked for the way to implement it, starting from a simple one which already works. I was wrong. The disagreement started about the need itself and slipped to the level at which implementation should be done. I would really like to reach a compromise on this issue, something that could by accepted by everybody. I don't want to get banned with a -1 on a commit, but at least a few people would like localized error messages that can be simply forwarded upward from lower layers to upper layer for display without processing. Standard java already provides Throwable.getLocalizedMessage() since JDK 1.1. I could set up for [math] only an exception hierarchy that only add a few constructors and an implementation of this method without any change in the Throwable.getMessage() behaviour. Does this sound reasonable ? Sorry I was out of pocket this week and could not reiterate my personal +1 for moving forward as you suggest, Luc. I will add a few of more comments below. If anyone still has serious reservations - especially those who now or in the future may contribute to [math] - pls speak up; otherwise we can move on. Thanks to all who provided comments. 1) My initial +1 was based on the fact that the error management that
Re: [all] exceptions and localization
How would they subclass? The commons math code will be throwing these exceptions themselves, no? They wouldn't be able to tell commons math to throw a specific type of exception class that they wrote. I agree that the default case (the JDK's getMessage() method) should work so that nobody has to know about the special i18n facilities. But, if you're truly looking to provide a rich i18n framework for exceptions, you need to make it extensible/adaptable. On 2/3/07, Phil Steitz [EMAIL PROTECTED] wrote: On 2/3/07, James Carman [EMAIL PROTECTED] wrote: How does a calling application override the message, if they wish? They could subclass and override translate() or, assuming we take your suggestion and carry the data along, they could access the data and do whatever they want with it. I agree that it is a good idea to persist and expose the key and parts. I just also think it is good for getMessage() and getMessage(Locale) to provide default localization out of the box. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
On 2/3/07, James Carman [EMAIL PROTECTED] wrote: How would they subclass? The commons math code will be throwing these exceptions themselves, no? They wouldn't be able to tell commons math to throw a specific type of exception class that they wrote. Yes, you're right. I agree that the default case (the JDK's getMessage() method) should work so that nobody has to know about the special i18n facilities. But, if you're truly looking to provide a rich i18n framework for exceptions, you need to make it extensible/adaptable. I think exposing the key and parts and adding getMessage(Locale) is probably good enough. Phil
