[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 74 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO]

[GUMP@vmgump]: Project commons-jelly-tags-sql (in module commons-jelly) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-jelly-tags-sql has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 2 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-sql :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-jelly-tags-sql-12092012.jar] identifier set 
to project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property 
maven.jar.commons-jexl.
 -DEBUG- (Apache Gump generated) Apache Maven Properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.xml
 -DEBUG- Maven project properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.properties
 -INFO- Project Reports in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/gump_work/build_commons-jelly_commons-jelly-tags-sql.html
Work Name: build_commons-jelly_commons-jelly-tags-sql (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: maven --offline jar 
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/sql]
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

You are working offline so the build will continue, but 
commons-jelly-1.1-SNAPSHOT.jar may be out of date!
build:start:

java:prepare-filesystem:
[mkdir] Created dir: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes

java:compile:
[echo] Compiling to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] Compiling 18 source files to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.5
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/src/java/org/apache/commons/jelly/tags/sql/DataSourceWrapper.java:38:
 error: DataSourceWrapper is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class DataSourceWrapper implements DataSource {
[javac]^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 1 warning

BUILD FAILED
File.. /home/gump/.maven/cache/maven-java-plugin-1.5/plugin.jelly
Element... ant:javac
Line.. 63
Column 48
Compile failed; see the compiler error output for details.
Total time: 6 seconds
Finished at: Wed Sep 12 07:13:47 UTC 2012

-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1212092012, vmgump.apache.org:vmgump:1212092012
Gump E-mail Identifier (unique within run) #61.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CSV] Release status?

[Simone Tripodi]

>> Any agreement (or objection) on changing that?
>
> Why? CSV is an acronym and as such capital letters are OK.

I remember a thread where we discussed about that, unfortunately I
cannot find it anymore (quickly tried a little on markmail but with no
success) - not sure we arrived somewhere - but I remember there where
two "schools of thought" about it: I personally prefer the Gary's one,
i.e. XmlParser rather than XMLParser.

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Codec 1.7-RC2

[Simone Tripodi]

+1

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, Sep 11, 2012 at 2:26 PM, Gary Gregory  wrote:
> Hello All:
>
> This is a VOTE to release Commons Codec 1.7-RC2.
>
> The differences with RC1 are:
>
> - Added missing ASF header to Sha2CryptTest.java
> - Fixed failing tests on IBM JVM and removed related release notes
> documentation.
> - Changes in changes.xml.
> - Added JRE requirement to release notes.
>
> Commons Codec 1.7 requires a minimum of Java 1.6
>
> Changes in this version include:
>
> New features:
> o CODEC-157:  DigestUtils: Add MD2 APIs. Thanks to ggregory.
> o CODEC-156:  DigestUtils: add APIs named after standard algorithm name
> SHA-1. Thanks to ggregory.
> o CODEC-155:  DigestUtils.getDigest(String) should throw
> IllegalArgumentException instead of RuntimeException. Thanks to ggregory.
> o CODEC-153:  Create a class MessageDigestAlgorithms to define standard
> algorithm names. Thanks to ggregory.
> o CODEC-152:  DigestUtils.getDigest(String) loses the original exception.
> Thanks to ggregory.
> o CODEC-151:  Remove unnecessary attempt to fill up the salt variable in
> UnixCrypt. Thanks to lathspell.
> o CODEC-150:  Remove unnecessary call to Math.abs(). Thanks to lathspell.
> o CODEC-148:  More tests and minor things. Thanks to lathspell.
> o CODEC-146:  Added regression tests for PhoneticEngine based on
> Solr-3.6.0. Thanks to Julius Davies.
> o CODEC-139:  DigestUtils: add updateDigest methods and make methods
> public. Thanks to dsebastien.
> o CODEC-133:  Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash
> variants. Thanks to lathspell.
> o CODEC-130:  Base64InputStream.skip skips underlying stream, not output.
> Thanks to tn.
> o CODEC-63:   Implement NYSIIS phonetic encoder. Thanks to bayard.
>
> Fixed Bugs:
> o CODEC-96:   Base64 encode() method is no longer thread-safe, breaking
> clients using it as a shared BinaryEncoder.
>   Note: the fix breaks binary compatibility, however the
> changes are to a class (BaseNCodec) which is
>   intended for internal use. Thanks to sebb.
> o CODEC-138:  Complete FilterInputStream interface for
> BaseNCodecInputStream.
> o CODEC-136:  Use Charset objects when possible, create Charsets for
> required character encodings.
> o CODEC-132:  BeiderMorseEncoder OOM issues. Thanks to rcmuir.
> o CODEC-131:  DoubleMetaphone javadoc contains dead links. Thanks to smolav.
>
> Changes:
> o CODEC-147:  BeiderMorseEncoder/PhoneticEngine: make results deterministic
> by using a LinkedHashSet
>   instead of a HashSet.
> o CODEC-143:  StringBuffer could be replaced by StringBuilder for local
> variables.
>
> This VOTE is open for at least 72 hours until September 14 2012 at 9:30 AM
> EST.
>
> The files:
>
> https://repository.apache.org/content/repositories/orgapachecommons-051/
>
> The tag:
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC2
>
> The site:
>
> https://people.apache.org/builds/commons/commons-codec/1.7/RC2/
>
> Note that the JIRA report is empty and it is a known issue in the Maven
> JIRA plugin and that requires a new plugin version.
>
> Thank you,
> Gary Gregory
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CSV] Release status?

[Jörg Schaible]

Hi Simo,

Simone Tripodi wrote:

>>> Any agreement (or objection) on changing that?
>>
>> Why? CSV is an acronym and as such capital letters are OK.
> 
> I remember a thread where we discussed about that, unfortunately I
> cannot find it anymore (quickly tried a little on markmail but with no
> success) - not sure we arrived somewhere - but I remember there where
> two "schools of thought" about it: I personally prefer the Gary's one,
> i.e. XmlParser rather than XMLParser.

JDK has actually XMLWriter as well as XmlWriter :D

However, since is more of a personal preference, I'd not set up any rule for 
all Apache commons components, we should just try to keep it consistent 
within a component.

While I know that Gary would like to finalize the API for 1.0 I'd personally 
find it annoying if I had to change code just because of a personal 
preference (using SNAPSHOTs of CVS for long times - and I bet I am not the 
only one using SNAPSHOTs after so much years this component is floating 
around). As long as it's consistent I'd simply keep it now.

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CSV] Release status?

[Simone Tripodi]

Guten morgen, Jörg!

> JDK has actually XMLWriter as well as XmlWriter :D
>

lol indeed, that's fun! :D

> However, since is more of a personal preference, I'd not set up any rule for
> all Apache commons components, we should just try to keep it consistent
> within a component.
>

+1, no doubts!

> While I know that Gary would like to finalize the API for 1.0 I'd personally
> find it annoying if I had to change code just because of a personal
> preference (using SNAPSHOTs of CVS for long times - and I bet I am not the
> only one using SNAPSHOTs after so much years this component is floating
> around). As long as it's consistent I'd simply keep it now.

agreed, at Apache Any23 we are using CVS SNAPSHOTs as well, that would
imply a refactory...

all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Sep 12, 2012 at 11:24 AM, Jörg Schaible
 wrote:
> Hi Simo,
>
> Simone Tripodi wrote:
>
 Any agreement (or objection) on changing that?
>>>
>>> Why? CSV is an acronym and as such capital letters are OK.
>>
>> I remember a thread where we discussed about that, unfortunately I
>> cannot find it anymore (quickly tried a little on markmail but with no
>> success) - not sure we arrived somewhere - but I remember there where
>> two "schools of thought" about it: I personally prefer the Gary's one,
>> i.e. XmlParser rather than XMLParser.
>
> JDK has actually XMLWriter as well as XmlWriter :D
>
> However, since is more of a personal preference, I'd not set up any rule for
> all Apache commons components, we should just try to keep it consistent
> within a component.
>
> While I know that Gary would like to finalize the API for 1.0 I'd personally
> find it annoying if I had to change code just because of a personal
> preference (using SNAPSHOTs of CVS for long times - and I bet I am not the
> only one using SNAPSHOTs after so much years this component is floating
> around). As long as it's consistent I'd simply keep it now.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CSV] Release status?

[sebb]

On 12 September 2012 10:29, Simone Tripodi  wrote:
> Guten morgen, Jörg!
>
>> JDK has actually XMLWriter as well as XmlWriter :D
>>
>
> lol indeed, that's fun! :D
>
>> However, since is more of a personal preference, I'd not set up any rule for
>> all Apache commons components, we should just try to keep it consistent
>> within a component.
>>
>
> +1, no doubts!

+1, don't change.the names now.

There are still some outstanding JIRA bugs which need to be resolved
before first release because they may entail changes to the API.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1383747 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/resources/assets/org/apache/commons/math3/exception/util/ test/java/org/apache/com

[Gilles Sadowski]

Hi Sébastien.

> Author: celestin
> Date: Wed Sep 12 03:46:31 2012
> New Revision: 1383747
> 
> URL: http://svn.apache.org/viewvc?rev=1383747&view=rev
> Log:
> Added new localized error message "entry {0}" to signal null entries in 
> FieldVectors.
> 
> Modified:
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
> 
> commons/proper/math/trunk/src/main/resources/assets/org/apache/commons/math3/exception/util/LocalizedFormats_fr.properties
> 
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/exception/util/LocalizedFormatsTest.java
> 
> Modified: 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java?rev=1383747&r1=1383746&r2=1383747&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>  (original)
> +++ 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>  Wed Sep 12 03:46:31 2012
> @@ -97,6 +97,7 @@ public enum LocalizedFormats implements 
>  EMPTY_SELECTED_ROW_INDEX_ARRAY("empty selected row index array"),
>  EMPTY_STRING_FOR_IMAGINARY_CHARACTER("empty string for imaginary 
> character"),
>  ENDPOINTS_NOT_AN_INTERVAL("endpoints do not specify an interval: [{0}, 
> {1}]"),
> +ENTRY("entry {0}"),
>  EQUAL_VERTICES_IN_SIMPLEX("equal vertices {0} and {1} in simplex 
> configuration"),
>  EULER_ANGLES_SINGULARITY("Euler angles singularity"),
>  EVALUATION("evaluation"), /* keep */

Sorry, this is again a discussion that started before your arrival as CM
contributor. There are far too many of these enum instances (another of
what I call "little defects").
In particular, many convey similar meanings. Duplicates should be removed,
and especially none should be added. :-}

There is an INDEX instance, so that an ENTRY instance is not necessary in my
opinion.  [The word "index" represents precisely what's in the "{0}"
placeholder.]

Is there a reason to prefer ENTRY over INDEX?

Best,
Gilles

P.S. It is possible to "stack" messages (and thus instances of the enum) so
 as to add more information into the exception's detailed message.

> 
> Modified: 
> commons/proper/math/trunk/src/main/resources/assets/org/apache/commons/math3/exception/util/LocalizedFormats_fr.properties
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/resources/assets/org/apache/commons/math3/exception/util/LocalizedFormats_fr.properties?rev=1383747&r1=1383746&r2=1383747&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/main/resources/assets/org/apache/commons/math3/exception/util/LocalizedFormats_fr.properties
>  (original)
> +++ 
> commons/proper/math/trunk/src/main/resources/assets/org/apache/commons/math3/exception/util/LocalizedFormats_fr.properties
>  Wed Sep 12 03:46:31 2012
> @@ -69,6 +69,7 @@ EMPTY_SELECTED_COLUMN_INDEX_ARRAY = tabl
>  EMPTY_SELECTED_ROW_INDEX_ARRAY = tableau des indices de lignes 
> s\u00e9lectionn\u00e9es vide
>  EMPTY_STRING_FOR_IMAGINARY_CHARACTER = cha\u00eene vide pour le caract\u00e8 
> imaginaire
>  ENDPOINTS_NOT_AN_INTERVAL = les bornes ne d\u00e9finissent pas un intervalle 
> : [{0}, {1}]
> +ENTRY = \u00e9l\u00e9ment {0}
>  EQUAL_VERTICES_IN_SIMPLEX = sommets {0} et {1} \u00e9gaux dans la 
> configuration du simplex
>  EULER_ANGLES_SINGULARITY = singularit\u00e9 d''angles d''Euler
>  EVALUATION = \u00e9valuation
> 
> Modified: 
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/exception/util/LocalizedFormatsTest.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math3/exception/util/LocalizedFormatsTest.java?rev=1383747&r1=1383746&r2=1383747&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/exception/util/LocalizedFormatsTest.java
>  (original)
> +++ 
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/exception/util/LocalizedFormatsTest.java
>  Wed Sep 12 03:46:31 2012
> @@ -36,7 +36,7 @@ public class LocalizedFormatsTest {
>  
>  @Test
>  public void testMessageNumber() {
> -Assert.assertEquals(310, LocalizedFormats.values().length);
> +Assert.assertEquals(311, LocalizedFormats.values().length);
>  }
>  
>  @Test
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1383770 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/java/org/apache/commons/math3/linear/ main/resources/assets/org/apache/commons/mat

[Gilles Sadowski]

Hello Sébastien.

On Wed, Sep 12, 2012 at 04:43:39AM -, celes...@apache.org wrote:
> Author: celestin
> Date: Wed Sep 12 04:43:38 2012
> New Revision: 1383770
> 
> URL: http://svn.apache.org/viewvc?rev=1383770&view=rev
> Log:
> Removed LocalizedFormats.ENTRY previously introduced in r1383747, as 
> LocalizedFormats.INDEX will do nicely.
> 
> Modified:
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
> 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
> 
> commons/proper/math/trunk/src/main/resources/assets/org/apache/commons/math3/exception/util/LocalizedFormats_fr.properties
> 
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/exception/util/LocalizedFormatsTest.java
> 
> Modified: 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java?rev=1383770&r1=1383769&r2=1383770&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>  (original)
> +++ 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>  Wed Sep 12 04:43:38 2012
> @@ -97,7 +97,6 @@ public enum LocalizedFormats implements 
>  EMPTY_SELECTED_ROW_INDEX_ARRAY("empty selected row index array"),
>  EMPTY_STRING_FOR_IMAGINARY_CHARACTER("empty string for imaginary 
> character"),
>  ENDPOINTS_NOT_AN_INTERVAL("endpoints do not specify an interval: [{0}, 
> {1}]"),
> -ENTRY("entry {0}"),
>  EQUAL_VERTICES_IN_SIMPLEX("equal vertices {0} and {1} in simplex 
> configuration"),
>  EULER_ANGLES_SINGULARITY("Euler angles singularity"),
>  EVALUATION("evaluation"), /* keep */

Please discard my previous message...
Again one disability of mine (apart from not being an HTML parser): I
process messages sequentially. :-) Sorry.

But, there was something else:

> 
> Modified: 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java?rev=1383770&r1=1383769&r2=1383770&view=diff
> ==
> --- 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
>  (original)
> +++ 
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
>  Wed Sep 12 04:43:38 2012
> @@ -560,7 +560,7 @@ public class ArrayFieldVector  try {
>  out[i] = one.divide(data[i]);
>  } catch (final MathArithmeticException e) {
> -throw new MathArithmeticException(LocalizedFormats.ENTRY, i);
> +throw new MathArithmeticException(LocalizedFormats.INDEX, i);
>  }
>  }

Do we really want to do this instead of checking a precondition (or do
nothin at that level)? I know that it would be preferrable to (also) report
the INDEX, but on the other hand, this kind of code becomes really ugly (in
the sense that there are more signs related to failure detection and
handling than to the "interesting stuff".

Moreover, you can an exception and completely discard the information it
might have contained! [In this case, the info might likely have been
"division by zero".]

Finally a more general point: In the "FieldElement" interface, there is
---
/** Compute this ÷ a.
 * @param a element to add
 * @return a new element representing this ÷ a
 * @throws NullArgumentException if {@code a} is {@code null}.
 * @throws MathArithmeticException if {@code a} is zero
 */
T divide(T a) throws NullArgumentException, MathArithmeticException;
---

This is another example of what I pointed to a few days ago: Documenting
MathArithmeticException is wrong because not all implementations behave that
way (e.g. "Complex"). [Alternatively, it can be construed that "Complex" is
not correctly implemented (cf. MATH-667).]

[There is also a typo in the description of param "a".]

Best regards,
Gilles

>  return new ArrayFieldVector(field, out, false);
> @@ -573,7 +573,7 @@ public class ArrayFieldVector  try {
>  data[i] = one.divide(data[i]);
>  } catch (final MathArithmeticException e) {
> -throw new MathArithmeticException(LocalizedFormats.ENTRY, i);
> +throw new MathArithmeticException(LocalizedFormats.INDEX, i);
>  }
>  }
>  return this;
> @@ -623,7 +623,7 @@ public class ArrayFieldVector  try {
>  out[i] = data[i].divide

Re: svn commit: r1383770 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/java/org/apache/commons/math3/linear/ main/resources/assets/org/apache/commons/mat

[Sébastien Brisard]

Hi Gilles,

2012/9/12 Gilles Sadowski :
> Hello Sébastien.
>
> On Wed, Sep 12, 2012 at 04:43:39AM -, celes...@apache.org wrote:
>> Author: celestin
>> Date: Wed Sep 12 04:43:38 2012
>> New Revision: 1383770
>>
>> URL: http://svn.apache.org/viewvc?rev=1383770&view=rev
>> Log:
>> Removed LocalizedFormats.ENTRY previously introduced in r1383747, as 
>> LocalizedFormats.INDEX will do nicely.
>>
>> Modified:
>> 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>> 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
>> 
>> commons/proper/math/trunk/src/main/resources/assets/org/apache/commons/math3/exception/util/LocalizedFormats_fr.properties
>> 
>> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/exception/util/LocalizedFormatsTest.java
>>
>> Modified: 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java?rev=1383770&r1=1383769&r2=1383770&view=diff
>> ==
>> --- 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>>  (original)
>> +++ 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
>>  Wed Sep 12 04:43:38 2012
>> @@ -97,7 +97,6 @@ public enum LocalizedFormats implements
>>  EMPTY_SELECTED_ROW_INDEX_ARRAY("empty selected row index array"),
>>  EMPTY_STRING_FOR_IMAGINARY_CHARACTER("empty string for imaginary 
>> character"),
>>  ENDPOINTS_NOT_AN_INTERVAL("endpoints do not specify an interval: [{0}, 
>> {1}]"),
>> -ENTRY("entry {0}"),
>>  EQUAL_VERTICES_IN_SIMPLEX("equal vertices {0} and {1} in simplex 
>> configuration"),
>>  EULER_ANGLES_SINGULARITY("Euler angles singularity"),
>>  EVALUATION("evaluation"), /* keep */
>
> Please discard my previous message...
> Again one disability of mine (apart from not being an HTML parser): I
> process messages sequentially. :-) Sorry.
>
As for me, I can't read emails (you pointed at INDEX in one of your
previous messages...).

>
> But, there was something else:
>
>>
>> Modified: 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java?rev=1383770&r1=1383769&r2=1383770&view=diff
>> ==
>> --- 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
>>  (original)
>> +++ 
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
>>  Wed Sep 12 04:43:38 2012
>> @@ -560,7 +560,7 @@ public class ArrayFieldVector>  try {
>>  out[i] = one.divide(data[i]);
>>  } catch (final MathArithmeticException e) {
>> -throw new MathArithmeticException(LocalizedFormats.ENTRY, 
>> i);
>> +throw new MathArithmeticException(LocalizedFormats.INDEX, 
>> i);
>>  }
>>  }
>
> Do we really want to do this instead of checking a precondition (or do
> nothin at that level)? I know that it would be preferrable to (also) report
> the INDEX, but on the other hand, this kind of code becomes really ugly (in
> the sense that there are more signs related to failure detection and
> handling than to the "interesting stuff".
>
I agree that it is ugly. I would like to know what others think. I'm
perfectly happy propagating a MathArithmeticException which does not
report on the index.

> Moreover, you can an exception and completely discard the information it
> might have contained! [In this case, the info might likely have been
> "division by zero".]
>
> Finally a more general point: In the "FieldElement" interface, there is
> ---
> /** Compute this ÷ a.
>  * @param a element to add
>  * @return a new element representing this ÷ a
>  * @throws NullArgumentException if {@code a} is {@code null}.
>  * @throws MathArithmeticException if {@code a} is zero
>  */
> T divide(T a) throws NullArgumentException, MathArithmeticException;
> ---
>
> This is another example of what I pointed to a few days ago: Documenting
> MathArithmeticException is wrong because not all implementations behave that
> way (e.g. "Complex"). [Alternatively, it can be construed that "Complex" is
> not correctly implemented (cf. MATH-667).]
>
> [There is also a typo in the description of param "a".]
>
> Best regards,
> Gilles
>
For what it's worth, Decimal64 does not throw an exception either. So
maybe MathArithmeticException should be removed from the signature of
Field

Re: [Math] About "NullArgumentException"

[Gilles Sadowski]

On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
> Hi Phil,
> 
> 2012/9/10 Phil Steitz :
> > On 9/10/12 11:47 AM, Sébastien Brisard wrote:
> >> Hi
> >> What should I do there?
> >> I'm trying to work on MATH-854. It turns out that FieldElement.add
> >> throws a NAE. Should I catch it below, and rethrow it with a more
> >> detailed message (including the entry index)?
> >
> > IMO, yes.
> >
> > I would also check v itself and add to the javadoc contract that IAE
> > is thrown if v is null.  This is not consistently done in [math],
> > though, and rarely in the linear package, so I am OK just letting
> > the NPE propagate if v is null.   It is a little awkward that v
> > itself being null leads to NPE, but a component of it null leads to
> > MIAE.
> >
> I agree with you, it feels weird. I found a better way: we need to
> make sure that entries of FieldVector can *never* be null. This means
> checking for null in setters, constructors and the likes. What do you
> think?

That would certainly simplify some code.
But (devil's advocate) should we consider that some people may rely on the
possibility to set "null" entries?


Gilles

> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] About "NullArgumentException"

[Sébastien Brisard]

Hi Gilles,

2012/9/12 Gilles Sadowski :
> On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
>> Hi Phil,
>>
>> 2012/9/10 Phil Steitz :
>> > On 9/10/12 11:47 AM, Sébastien Brisard wrote:
>> >> Hi
>> >> What should I do there?
>> >> I'm trying to work on MATH-854. It turns out that FieldElement.add
>> >> throws a NAE. Should I catch it below, and rethrow it with a more
>> >> detailed message (including the entry index)?
>> >
>> > IMO, yes.
>> >
>> > I would also check v itself and add to the javadoc contract that IAE
>> > is thrown if v is null.  This is not consistently done in [math],
>> > though, and rarely in the linear package, so I am OK just letting
>> > the NPE propagate if v is null.   It is a little awkward that v
>> > itself being null leads to NPE, but a component of it null leads to
>> > MIAE.
>> >
>> I agree with you, it feels weird. I found a better way: we need to
>> make sure that entries of FieldVector can *never* be null. This means
>> checking for null in setters, constructors and the likes. What do you
>> think?
>
> That would certainly simplify some code.
> But (devil's advocate) should we consider that some people may rely on the
> possibility to set "null" entries?
>
Yes, didn't think of that. However, the javadoc does not specify that
null is allowed. So referring to earlier discussions, that should mean
that it is forbidden... I'm stretching the argument a little bit, I
know.
Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1383770 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/java/org/apache/commons/math3/linear/ main/resources/assets/org/apache/commons/mat

[Gilles Sadowski]

> >
> > Please discard my previous message...
> > Again one disability of mine (apart from not being an HTML parser): I
> > process messages sequentially. :-) Sorry.
> >
> As for me, I can't read emails (you pointed at INDEX in one of your
> previous messages...).

So we are even. ;-)

> 
> >
> > But, there was something else:
> >
> >>
> >> Modified: 
> >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
> >> URL: 
> >> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java?rev=1383770&r1=1383769&r2=1383770&view=diff
> >> ==
> >> --- 
> >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
> >>  (original)
> >> +++ 
> >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java
> >>  Wed Sep 12 04:43:38 2012
> >> @@ -560,7 +560,7 @@ public class ArrayFieldVector >>  try {
> >>  out[i] = one.divide(data[i]);
> >>  } catch (final MathArithmeticException e) {
> >> -throw new MathArithmeticException(LocalizedFormats.ENTRY, 
> >> i);
> >> +throw new MathArithmeticException(LocalizedFormats.INDEX, 
> >> i);
> >>  }
> >>  }
> >
> > Do we really want to do this instead of checking a precondition (or do
> > nothin at that level)? I know that it would be preferrable to (also) report
> > the INDEX, but on the other hand, this kind of code becomes really ugly (in
> > the sense that there are more signs related to failure detection and
> > handling than to the "interesting stuff".
> >
> I agree that it is ugly. I would like to know what others think. I'm
> perfectly happy propagating a MathArithmeticException which does not
> report on the index.

If more messages is always is better, we might have to get used to this kind
of construct...

> 
> > Moreover, you can an exception and completely discard the information it
> > might have contained! [In this case, the info might likely have been
> > "division by zero".]

... but the original message(s) should definitely be kept:

   try {
 out[i] = one.divide(data[i]);
   } catch (MathArithmeticException e) {
 e.getContext().addMessage(LocalizedFormats.ENTRY, i);
 throw e;
   }

> >
> > Finally a more general point: In the "FieldElement" interface, there is
> > ---
> > /** Compute this ÷ a.
> >  * @param a element to add
> >  * @return a new element representing this ÷ a
> >  * @throws NullArgumentException if {@code a} is {@code null}.
> >  * @throws MathArithmeticException if {@code a} is zero
> >  */
> > T divide(T a) throws NullArgumentException, MathArithmeticException;
> > ---
> >
> > This is another example of what I pointed to a few days ago: Documenting
> > MathArithmeticException is wrong because not all implementations behave that
> > way (e.g. "Complex"). [Alternatively, it can be construed that "Complex" is
> > not correctly implemented (cf. MATH-667).]
> >
> > [There is also a typo in the description of param "a".]
> >
> > Best regards,
> > Gilles
> >
> For what it's worth, Decimal64 does not throw an exception either. So
> maybe MathArithmeticException should be removed from the signature of
> FieldElement.divide(), as it's clearly not part of the contract of
> this method.

No runtime exception can be part of an enforceable contract.
We should not advertize that _interface_ methods throw exceptions; only
exceptions that can actually be thrown should be documented.


> However, some fields do not know NaN, and it would be nice to have a
> guidance in the javadoc of the interface, regarding what exception
> should be thrown.

Various use-cases could be mentioned.

Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] About "NullArgumentException"

[Gilles Sadowski]

On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
> Hi Gilles,
> 
> 2012/9/12 Gilles Sadowski :
> > On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
> >> Hi Phil,
> >>
> >> 2012/9/10 Phil Steitz :
> >> > On 9/10/12 11:47 AM, Sébastien Brisard wrote:
> >> >> Hi
> >> >> What should I do there?
> >> >> I'm trying to work on MATH-854. It turns out that FieldElement.add
> >> >> throws a NAE. Should I catch it below, and rethrow it with a more
> >> >> detailed message (including the entry index)?
> >> >
> >> > IMO, yes.
> >> >
> >> > I would also check v itself and add to the javadoc contract that IAE
> >> > is thrown if v is null.  This is not consistently done in [math],
> >> > though, and rarely in the linear package, so I am OK just letting
> >> > the NPE propagate if v is null.   It is a little awkward that v
> >> > itself being null leads to NPE, but a component of it null leads to
> >> > MIAE.
> >> >
> >> I agree with you, it feels weird. I found a better way: we need to
> >> make sure that entries of FieldVector can *never* be null. This means
> >> checking for null in setters, constructors and the likes. What do you
> >> think?
> >
> > That would certainly simplify some code.
> > But (devil's advocate) should we consider that some people may rely on the
> > possibility to set "null" entries?
> >
> Yes, didn't think of that. However, the javadoc does not specify that
> null is allowed. So referring to earlier discussions, that should mean
> that it is forbidden... I'm stretching the argument a little bit, I
> know.

That's fine with me. In the sense that it is IMHO a _developer_'s choice:
It's a statement about the library ("We decide for consistency and
robustness reasons, that "null" is forbidden").
I contend that it is the same kind of argument that led most of us to prefer
immutable instances (even if some users might want to have mutable ones).


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[math] silly classes naming question

[Luc Maisonobe]

Hi all,

Continuing the work on the new differentiation framework, I am facing a
silly naming problem. This problem is exactly the same I encountered
while I updated the solvers: the Java language does not allow to inherit
from the same parameterized interface with two different parameters.

So when I want to update class LevenbergMarquardtOptimizer which extends
AbstractLeastSquaresOptimizer which itself extends
BaseAbstractMultivariateVectorOptimizer,
I hit the problem. I cannot have
BaseAbstractMultivariateVectorOptimizer
in the same hierarchy.

For solvers, we decided to duplicate the hierarchy, and I ended up
creating a new NewtonRaphsonSolver while deprecating the older
NewtonSolver. I would like to do the same for the optimizers.

As the intermediate class AbstractLeastSquaresOptimizer is not really
something most users will use, a simple name change to
AbstractLSOptimizer seems sufficient. Such simple name changes would not
be good for end-users classes like LevenbergMarquardtOptimizer,
NonLinearConjugateGradientOptimizer or GaussNewtonOptimizer. Note that
the core algorithms do not change at all, only the signatures change as
well as one line in AbstractLeastSquaresOptimizer (to be precise, the
changed line is from: "jF = f.jacobian()" to "jf = jF = new
JacobianFunction(f)").

Does someone has clever name changes to propose or should I simply keep
only the existing classes, add the new signatures but do not declare
them as implementing top level parameterized interfaces?

I'm sorry to ask such silly questions, but I am stuck with this Java
limitation.

best regards,
Luc

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Towards release 3.1

[Gilles Sadowski]

Hello.

This thread was left alone for some time, although the main issue was not
settled: I requested the release of a new version of CM.

I quote my remarks from an earlier message in this thread:

> [...] issues resulted in some work being done, [...]
> My opinion is that releases must reflect that fact. Or, conversely, only
> "nothing new happened" is a reason for not providing a new release.
> 
> Of course, there should be a balance between the work imposed by preparing a
> release, and the updated contents to be released. I think that the trade-off
> is already largely positive.

and

> > > "Wish" or "improvement" issues that miss a patch should not be blocking 
> > > the
> > > 3.1 release.

and

> Of course, I'd be all for setting a date for release 3.2 too! 

Context:
I have to abide by the requirement to use an _official_ release of CM and my
code relies on bug fixes present in the development version.

Are there any technical reasons to object to the starting of the release
process?


Thanks for your attention,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Towards release 3.1

[Luc Maisonobe]

Le 12/09/2012 14:04, Gilles Sadowski a écrit :
> Hello.
> 
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
> 
> I quote my remarks from an earlier message in this thread:
> 
>> [...] issues resulted in some work being done, [...]
>> My opinion is that releases must reflect that fact. Or, conversely, only
>> "nothing new happened" is a reason for not providing a new release.
>>
>> Of course, there should be a balance between the work imposed by preparing a
>> release, and the updated contents to be released. I think that the trade-off
>> is already largely positive.
> 
> and
> 
 "Wish" or "improvement" issues that miss a patch should not be blocking the
 3.1 release.
> 
> and
> 
>> Of course, I'd be all for setting a date for release 3.2 too! 
> 
> Context:
> I have to abide by the requirement to use an _official_ release of CM and my
> code relies on bug fixes present in the development version.
> 
> Are there any technical reasons to object to the starting of the release
> process?

I would also be glad to see 3.1 out.
As far as I am concerned, the work on differentiation is almost ready.
If we can solve the silly problem I mentioned in another message a few
minutes ago, I would be happy to finish that and release 3.1.

Luc

> 
> 
> Thanks for your attention,
> Gilles
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Towards release 3.1

[Sébastien Brisard]

Hi Gilles,

2012/9/12 Gilles Sadowski :
> Hello.
>
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
>
> I quote my remarks from an earlier message in this thread:
>
>> [...] issues resulted in some work being done, [...]
>> My opinion is that releases must reflect that fact. Or, conversely, only
>> "nothing new happened" is a reason for not providing a new release.
>>
>> Of course, there should be a balance between the work imposed by preparing a
>> release, and the updated contents to be released. I think that the trade-off
>> is already largely positive.
>
> and
>
>> > > "Wish" or "improvement" issues that miss a patch should not be blocking 
>> > > the
>> > > 3.1 release.
>
> and
>
>> Of course, I'd be all for setting a date for release 3.2 too!
>
> Context:
> I have to abide by the requirement to use an _official_ release of CM and my
> code relies on bug fixes present in the development version.
>
> Are there any technical reasons to object to the starting of the release
> process?
>
If you did not have this precise requirement, I would have been a bit
reluctant to release 3.1 in the middle of MATH-854. Considering your
situation, I don't see any real objection on my side.
(Sparse vectors *will* be deprecated, as only Phil answered, but this
will wait until 3.2...).
Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] About "NullArgumentException"

[Sébastien Brisard]

2012/9/12 Gilles Sadowski :
> On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
>> Hi Gilles,
>>
>> 2012/9/12 Gilles Sadowski :
>> > On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
>> >> Hi Phil,
>> >>
>> >> 2012/9/10 Phil Steitz :
>> >> > On 9/10/12 11:47 AM, Sébastien Brisard wrote:
>> >> >> Hi
>> >> >> What should I do there?
>> >> >> I'm trying to work on MATH-854. It turns out that FieldElement.add
>> >> >> throws a NAE. Should I catch it below, and rethrow it with a more
>> >> >> detailed message (including the entry index)?
>> >> >
>> >> > IMO, yes.
>> >> >
>> >> > I would also check v itself and add to the javadoc contract that IAE
>> >> > is thrown if v is null.  This is not consistently done in [math],
>> >> > though, and rarely in the linear package, so I am OK just letting
>> >> > the NPE propagate if v is null.   It is a little awkward that v
>> >> > itself being null leads to NPE, but a component of it null leads to
>> >> > MIAE.
>> >> >
>> >> I agree with you, it feels weird. I found a better way: we need to
>> >> make sure that entries of FieldVector can *never* be null. This means
>> >> checking for null in setters, constructors and the likes. What do you
>> >> think?
>> >
>> > That would certainly simplify some code.
>> > But (devil's advocate) should we consider that some people may rely on the
>> > possibility to set "null" entries?
>> >
>> Yes, didn't think of that. However, the javadoc does not specify that
>> null is allowed. So referring to earlier discussions, that should mean
>> that it is forbidden... I'm stretching the argument a little bit, I
>> know.
>
> That's fine with me. In the sense that it is IMHO a _developer_'s choice:
> It's a statement about the library ("We decide for consistency and
> robustness reasons, that "null" is forbidden").
> I contend that it is the same kind of argument that led most of us to prefer
> immutable instances (even if some users might want to have mutable ones).
>
Fine, then. I'll implement null checks in all setters and
constructors, so that it is guaranteed that null will never be met
elsewhere.
I will modify the javadoc of the interface to clearly state that null
values should not be accepted, and that a MNAE should be thrown in
that case.
Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1383770 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/java/org/apache/commons/math3/linear/ main/resources/assets/org/apache/commons/mat

[Sébastien Brisard]

>> >>  } catch (final MathArithmeticException e) {
>> >> -throw new 
>> >> MathArithmeticException(LocalizedFormats.ENTRY, i);
>> >> +throw new 
>> >> MathArithmeticException(LocalizedFormats.INDEX, i);
>> >>  }
>> >>  }
>> >
>> > Do we really want to do this instead of checking a precondition (or do
>> > nothin at that level)? I know that it would be preferrable to (also) report
>> > the INDEX, but on the other hand, this kind of code becomes really ugly (in
>> > the sense that there are more signs related to failure detection and
>> > handling than to the "interesting stuff".
>> >
>> I agree that it is ugly. I would like to know what others think. I'm
>> perfectly happy propagating a MathArithmeticException which does not
>> report on the index.
>
> If more messages is always is better, we might have to get used to this kind
> of construct...
>
>>
>> > Moreover, you can an exception and completely discard the information it
>> > might have contained! [In this case, the info might likely have been
>> > "division by zero".]
>
> ... but the original message(s) should definitely be kept:
>
>try {
>  out[i] = one.divide(data[i]);
>} catch (MathArithmeticException e) {
>  e.getContext().addMessage(LocalizedFormats.ENTRY, i);
>  throw e;
>}
>
Good idea. I wasn't aware of this possibility until your previous
message. Thanks for the tip!

>> >
>> > Finally a more general point: In the "FieldElement" interface, there is
>> > ---
>> > /** Compute this ÷ a.
>> >  * @param a element to add
>> >  * @return a new element representing this ÷ a
>> >  * @throws NullArgumentException if {@code a} is {@code null}.
>> >  * @throws MathArithmeticException if {@code a} is zero
>> >  */
>> > T divide(T a) throws NullArgumentException, MathArithmeticException;
>> > ---
>> >
>> > This is another example of what I pointed to a few days ago: Documenting
>> > MathArithmeticException is wrong because not all implementations behave 
>> > that
>> > way (e.g. "Complex"). [Alternatively, it can be construed that "Complex" is
>> > not correctly implemented (cf. MATH-667).]
>> >
>> > [There is also a typo in the description of param "a".]
>> >
>> > Best regards,
>> > Gilles
>> >
>> For what it's worth, Decimal64 does not throw an exception either. So
>> maybe MathArithmeticException should be removed from the signature of
>> FieldElement.divide(), as it's clearly not part of the contract of
>> this method.
>
> No runtime exception can be part of an enforceable contract.
> We should not advertize that _interface_ methods throw exceptions; only
> exceptions that can actually be thrown should be documented.
>
OK, I'll go back to some changes I've done for the sake of MATH-854,
then. I thought that exceptions which *were* thrown by any
implementation ought to be advertised in the interface.
What I liked in this way of doing things is that people who want to
implement a given interface can do so consistently, even in the case
of exceptional situations. They do not have to think "hmmm, what
exception should I throw in this specific case?".

What I'll do instead is remove all throws clauses, and add Javadoc
comments like "implementations should throw a XxxException when
[...]". How does that sound?

>
>> However, some fields do not know NaN, and it would be nice to have a
>> guidance in the javadoc of the interface, regarding what exception
>> should be thrown.
>
> Various use-cases could be mentioned.
>
... Will do that in the Javadoc (see my comment above).

Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CSV] Release status?

[Gary Gregory]

On Wed, Sep 12, 2012 at 2:02 AM, Jörg Schaible
wrote:

> Hi Gary,
>
> Gary Gregory wrote:
>
> > Hi All:
> >
> > What left to be done to release a [CSV] 1.0?
> >
> > The one thing I do not like are all the CSVFoo and CSVBar class names. I
> > like CsvFoo and CsvBar better.
> >
> > Any agreement (or objection) on changing that?
>
> Why? CSV is an acronym and as such capital letters are OK.
>

In general, IMO, no, an acronym should be a word in the camel-case context.
The last letter of an all caps acronym merges with the first letter of the
next word. Worse still is the case where more than one acronym follow each
other.

IMO, this is horrendous:

IBMXMLDOMToSAXConverter

This is much better:

IbmXmlDomToSaxConverter

When I see CSVParser, I see "CSVP" and then have to tease out that the last
letter of is really the first letter of the next word. Lame.

That my opinion of course and the guideline we have at work.

Gary

>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Towards release 3.1

[Thomas Neidhart]

On Wed, Sep 12, 2012 at 2:04 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:

> Hello.
>
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
>
> I quote my remarks from an earlier message in this thread:
>
> > [...] issues resulted in some work being done, [...]
> > My opinion is that releases must reflect that fact. Or, conversely, only
> > "nothing new happened" is a reason for not providing a new release.
> >
> > Of course, there should be a balance between the work imposed by
> preparing a
> > release, and the updated contents to be released. I think that the
> trade-off
> > is already largely positive.
>
> and
>
> > > > "Wish" or "improvement" issues that miss a patch should not be
> blocking the
> > > > 3.1 release.
>
> and
>
> > Of course, I'd be all for setting a date for release 3.2 too!
>
> Context:
> I have to abide by the requirement to use an _official_ release of CM and
> my
> code relies on bug fixes present in the development version.
>
> Are there any technical reasons to object to the starting of the release
> process?
>

Hi Gilles, all,

I support the release request and we are already in September anyway (which
was the envisioned release time of CM 3.1 afaikr).
Regarding open issues from my side:

 * I would like to fix MATH-848 before the release but will have time the
next 2 weeks
 * MATH-789: I did an initial analysis but failed to further proceed, maybe
Luc can take a look?
 * MATH-842: the fix I made seems to work, but needs more investigation,
can be postponed
 * MATH-819: more like a general problem and may be resolved as WONT FIX,
TBD

The additions I proposed can all be postponed (and I need something to do
over winter ;-)

Cheers,

Thomas

Re: [Math] About "NullArgumentException"

[Phil Steitz]

On 9/12/12 5:14 AM, Sébastien Brisard wrote:
> 2012/9/12 Gilles Sadowski :
>> On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
>>> Hi Gilles,
>>>
>>> 2012/9/12 Gilles Sadowski :
 On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
> Hi Phil,
>
> 2012/9/10 Phil Steitz :
>> On 9/10/12 11:47 AM, Sébastien Brisard wrote:
>>> Hi
>>> What should I do there?
>>> I'm trying to work on MATH-854. It turns out that FieldElement.add
>>> throws a NAE. Should I catch it below, and rethrow it with a more
>>> detailed message (including the entry index)?
>> IMO, yes.
>>
>> I would also check v itself and add to the javadoc contract that IAE
>> is thrown if v is null.  This is not consistently done in [math],
>> though, and rarely in the linear package, so I am OK just letting
>> the NPE propagate if v is null.   It is a little awkward that v
>> itself being null leads to NPE, but a component of it null leads to
>> MIAE.
>>
> I agree with you, it feels weird. I found a better way: we need to
> make sure that entries of FieldVector can *never* be null. This means
> checking for null in setters, constructors and the likes. What do you
> think?
 That would certainly simplify some code.
 But (devil's advocate) should we consider that some people may rely on the
 possibility to set "null" entries?

>>> Yes, didn't think of that. However, the javadoc does not specify that
>>> null is allowed. So referring to earlier discussions, that should mean
>>> that it is forbidden... I'm stretching the argument a little bit, I
>>> know.
>> That's fine with me. In the sense that it is IMHO a _developer_'s choice:
>> It's a statement about the library ("We decide for consistency and
>> robustness reasons, that "null" is forbidden").
>> I contend that it is the same kind of argument that led most of us to prefer
>> immutable instances (even if some users might want to have mutable ones).
>>
> Fine, then. I'll implement null checks in all setters and
> constructors, so that it is guaranteed that null will never be met
> elsewhere.
> I will modify the javadoc of the interface to clearly state that null
> values should not be accepted, and that a MNAE should be thrown in
> that case.

+1 Good idea that adds robustness.

It is not ideal, but as a general principle where the javadoc is
underspecified, it is IMO fair game to explicitly state
preconditions and add checks for them.  This amounts to fully
specifying the API contract.  Code that relies on undocumented
behavior can break in this case.  This is why it is best to specify
the contract as fully as possible.  We need to be kind and practical
when applying this principle though.  Assumptions that *lots of
users* are likely to be making made suddenly no longer true should
be avoided.  The present case is unlikely to be a practical problem
for anyone.

I know this is a little of a sore subject, but in this and other
cases where arguments violate documented preconditions, I think we
should throw IAE, which means MNAE is only appropriate as long as it
continues to subclass our surrogate for IAE - MIAE.

If I sound hard-headed here, it would be great if someone could
explain to me what is different about null arguments at the point of
method activation in an API that explicitly disallows them. 
Consider, e.g. an empty array or array indices that will lead to
index out of bounds errors in APIs that take arrays.  What is so
different about null?  All are bad arguments violating API contract,
all detected at method activation time -> IAE.

Phil
> Sébastien
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Towards release 3.1

[Phil Steitz]

On 9/12/12 5:04 AM, Gilles Sadowski wrote:
> Hello.
>
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
>
> I quote my remarks from an earlier message in this thread:
>
>> [...] issues resulted in some work being done, [...]
>> My opinion is that releases must reflect that fact. Or, conversely, only
>> "nothing new happened" is a reason for not providing a new release.
>>
>> Of course, there should be a balance between the work imposed by preparing a
>> release, and the updated contents to be released. I think that the trade-off
>> is already largely positive.
> and
>
 "Wish" or "improvement" issues that miss a patch should not be blocking the
 3.1 release.
> and
>
>> Of course, I'd be all for setting a date for release 3.2 too! 
> Context:
> I have to abide by the requirement to use an _official_ release of CM and my
> code relies on bug fixes present in the development version.
>
> Are there any technical reasons to object to the starting of the release
> process?

I have a couple of things in progress (the KS test / distribution
issue, making EmpiricalDistribution implement the distribution
interface) that could wait if everything else is ready.  All that is
*required* is that we resolve or push out all issues marked as 3.1. 
We can always follow with 3.2 or 3.1.1 soon, so I see no harm to
getting this out quickly.  I have been working on the stat package
throws stuff.  If I can have the weekend to finish, I could finish
that; otherwise we release with this issue partly done (which is OK
by me, as long as we push out the ticket).

Phil
>
>
> Thanks for your attention,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Towards release 3.1

[Sébastien Brisard]

> [...]
> I have been working on the stat package
> throws stuff.  If I can have the weekend to finish, I could finish
> that; otherwise we release with this issue partly done (which is OK
> by me, as long as we push out the ticket).
>
I'm still working on the linear package, and there is still a lot to
do, I'm not sure I can go through it all y the weekend...
Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] silly classes naming question

[Gilles Sadowski]

I think that "silly classes" should not be allowed in CM!
;-)

> Hi all,
> 
> Continuing the work on the new differentiation framework, I am facing a
> silly naming problem. This problem is exactly the same I encountered
> while I updated the solvers: the Java language does not allow to inherit
> from the same parameterized interface with two different parameters.
> 
> So when I want to update class LevenbergMarquardtOptimizer which extends
> AbstractLeastSquaresOptimizer which itself extends
> BaseAbstractMultivariateVectorOptimizer,
> I hit the problem. I cannot have
> BaseAbstractMultivariateVectorOptimizer
> in the same hierarchy.

But those are not interfaces: a given class cannot extend both.
And if you wanted to replace one parametric type by the other, wouldn't that
break compatibility?

I think that the problem is with the "implements" clause:

public abstract class AbstractLeastSquaresOptimizer
extends 
BaseAbstractMultivariateVectorOptimizer
implements DifferentiableMultivariateVectorOptimizer { /* ... */ }


because "DifferentiableMultivariateVectorOptimizer" inherits from a
parameterized interface:

public interface DifferentiableMultivariateVectorOptimizer
extends 
BaseMultivariateVectorOptimizer {}

So indeed "AbstractLeastSquaresOptimizer" cannot implement both
  BaseMultivariateVectorOptimizer
and
  BaseMultivariateVectorOptimizer


Is that correct?

> 
> For solvers, we decided to duplicate the hierarchy, and I ended up
> creating a new NewtonRaphsonSolver while deprecating the older
> NewtonSolver. I would like to do the same for the optimizers.
> 
> As the intermediate class AbstractLeastSquaresOptimizer is not really
> something most users will use, a simple name change to
> AbstractLSOptimizer seems sufficient.

I use it; namely I need the "getCovariances" functionality to compute them
at a point not necessarily obtained after running an optimizer that requires
derivatives.

> Such simple name changes would not
> be good for end-users classes like LevenbergMarquardtOptimizer,
> NonLinearConjugateGradientOptimizer or GaussNewtonOptimizer. Note that
> the core algorithms do not change at all, only the signatures change as
> well as one line in AbstractLeastSquaresOptimizer (to be precise, the
> changed line is from: "jF = f.jacobian()" to "jf = jF = new
> JacobianFunction(f)").
> 
> Does someone has clever name changes to propose or should I simply keep
> only the existing classes, add the new signatures but do not declare
> them as implementing top level parameterized interfaces?

That seems safe. But I don't fully understand the issue...

> I'm sorry to ask such silly questions, but I am stuck with this Java
> limitation.


Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] About "NullArgumentException"

[Gilles Sadowski]

> [...]
> 
> I know this is a little of a sore subject, but in this and other
> cases where arguments violate documented preconditions, I think we
> should throw IAE, which means MNAE is only appropriate as long as it
> continues to subclass our surrogate for IAE - MIAE.
> 
> If I sound hard-headed here, it would be great if someone could
> explain to me what is different about null arguments at the point of
> method activation in an API that explicitly disallows them. 
> Consider, e.g. an empty array or array indices that will lead to
> index out of bounds errors in APIs that take arrays.  What is so
> different about null?  All are bad arguments violating API contract,
> all detected at method activation time -> IAE.

Okay, I'm going to lay out again the arguments (all which I know about were
already mentioned in the thread).
[I'll try to demonstrate that where we differ is on the usefulness of having
a policy!]

Taking quotes from your mail in reversed order:

> All are bad arguments violating API contract,
> all detected at method activation time -> IAE.

Agreed... if the policy is to _always_ check for "null"!

If we sometimes check and sometimes not, the thrown exception will be from a
different hierarchy (NPE vs MathRuntimeException). This is annoying (and
inconsistent).

The oft-repeated issue is "Is it useful to check for null or not?"; at least
4 people answered "No", because this bug will never go unnoticed: sooner or
later, using "null" _will_ raise exception. The sole and unique difference
with CM checking and JVM checking is that the stack trace will (sometimes)
be a little shorter in the former case. Most people have come to agree that
it's not worth adopting a policy of thorough checking. [Rationale 1: users
who encounter a NPE will need to inspect the stack trace and go to _their_
code in order to see where _they_ put a "null". Rationale 2: there is
probably a performance penalty to all these checks (especially in a well
tested code where "null" reference bugs have been ironed out).]

> Consider, e.g. an empty array or array indices that will lead to
> index out of bounds errors in APIs that take arrays.  What is so
> different about null?

There is no difference... if there is a policy that decrees so.

It is _not_ the policy of the JDK: "NullPointerException" is not the same
error as "IndexOutOfBoundsException"; their common parent class is the
(unspecific) "RuntimeException" and their sibling is
"IllegalArgumentException".
There is no "is-a" relationship between NPE, IOBE and IAE.

Recalling that some 1.5 years ago you were against the adoption of the
single exception hierarchy, rooted at "MathRuntimeException", in order to
stay faithful to the JDK exception types, I wonder why you are on the
opposite stand as NPE is concerned.

> [...] what is different about null arguments at the point of
> method activation in an API that explicitly disallows them.

The difference is that there is no need to tell the user what the problem
is because the raised exception says it all: "You tried to use a null
reference." [As said above, the only issue is _when_ the exception is
triggered.]

The policy mandates what is globally valid, e.g.:
  "If not specified otherwise, "null" is not allowed as an argument."
Then, a user cannot complain about a NPE being propagated when he passed an
invalid (null) argument.

Finally, the case for "null" is also slightly peculiar (given the above)
that it should not simply be bundled with the rationale "Fail early": Indeed
"null" references always fail early (i.e. as soon as they are used).
Deferring the check until it is done by the JVM will never entails the code
to produce a wrong result _because_ of that null reference (it will just
fail in the predictable way: NPE).[1]


Gilles

[1] Unlike in C, where an unitialized pointer would not necessarily crash
the program, but _could_ make it behave erratically (including produce
wrong results in a stealth way).

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] silly classes naming question

[Luc Maisonobe]

Le 12/09/2012 16:32, Gilles Sadowski a écrit :
> 
> I think that "silly classes" should not be allowed in CM!

As all I am able to do is silly work, I should stop working for [math]
then ;-)

> ;-)
> 
>> Hi all,
>>
>> Continuing the work on the new differentiation framework, I am facing a
>> silly naming problem. This problem is exactly the same I encountered
>> while I updated the solvers: the Java language does not allow to inherit
>> from the same parameterized interface with two different parameters.
>>
>> So when I want to update class LevenbergMarquardtOptimizer which extends
>> AbstractLeastSquaresOptimizer which itself extends
>> BaseAbstractMultivariateVectorOptimizer,
>> I hit the problem. I cannot have
>> BaseAbstractMultivariateVectorOptimizer
>> in the same hierarchy.
> 
> But those are not interfaces: a given class cannot extend both.
> And if you wanted to replace one parametric type by the other, wouldn't that
> break compatibility?

Yes. What I wanted to do is implement both top level interfaces. The
fact there is an intermediate abstract class is irrelevant to me

> 
> I think that the problem is with the "implements" clause:
> 
> public abstract class AbstractLeastSquaresOptimizer
> extends 
> BaseAbstractMultivariateVectorOptimizer
> implements DifferentiableMultivariateVectorOptimizer { /* ... */ }
> 

Yes.

> 
> because "DifferentiableMultivariateVectorOptimizer" inherits from a
> parameterized interface:
> 
> public interface DifferentiableMultivariateVectorOptimizer
> extends 
> BaseMultivariateVectorOptimizer {}
> 
> So indeed "AbstractLeastSquaresOptimizer" cannot implement both
>   BaseMultivariateVectorOptimizer
> and
>   BaseMultivariateVectorOptimizer
> 
> 
> Is that correct?

Yes, it is the problem.

> 
>>
>> For solvers, we decided to duplicate the hierarchy, and I ended up
>> creating a new NewtonRaphsonSolver while deprecating the older
>> NewtonSolver. I would like to do the same for the optimizers.
>>
>> As the intermediate class AbstractLeastSquaresOptimizer is not really
>> something most users will use, a simple name change to
>> AbstractLSOptimizer seems sufficient.
> 
> I use it; namely I need the "getCovariances" functionality to compute them
> at a point not necessarily obtained after running an optimizer that requires
> derivatives.
> 
>> Such simple name changes would not
>> be good for end-users classes like LevenbergMarquardtOptimizer,
>> NonLinearConjugateGradientOptimizer or GaussNewtonOptimizer. Note that
>> the core algorithms do not change at all, only the signatures change as
>> well as one line in AbstractLeastSquaresOptimizer (to be precise, the
>> changed line is from: "jF = f.jacobian()" to "jf = jF = new
>> JacobianFunction(f)").
>>
>> Does someone has clever name changes to propose or should I simply keep
>> only the existing classes, add the new signatures but do not declare
>> them as implementing top level parameterized interfaces?
> 
> That seems safe. But I don't fully understand the issue...

Here is a really striped down version. Suppose we have a paremeterized
interface:
  interface TheInterface { public void f(T t); }

Then I could write this:

  class MyClass {
public void f(A a) { ... }
public void f(B b) { ... }
  }

But I could not write the following despite there are no type conflicts:

  class MyClass implements TheInterface, TheInterface {
public void f(A a) { ... }
public void f(B b) { ... }
  }

The workaround I propose is to write this:

  class MyClass implements TheInterface {
public void f(A a) { ... }
public void f(B b) { ... }
  }

I will do this with MyClass replaced by AbstractLeastSquaresOptimizer
and TheInterface replaced by BaseAbstractMultivariateVectorOptimizer. So
users will already be able to provide either a
DifferentiableMultivariateVectorFunction or a
MultivariateDifferentiableVectorFunction. This will help transition when
4.0 is out, and should not break compatibility between 3.0 and 3.1.

best regards,
Luc

> 
>> I'm sorry to ask such silly questions, but I am stuck with this Java
>> limitation.
> 
> 
> Gilles
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] About "NullArgumentException"

[Phil Steitz]

On 9/12/12 8:52 AM, Gilles Sadowski wrote:
>> [...]
>>
>> I know this is a little of a sore subject, but in this and other
>> cases where arguments violate documented preconditions, I think we
>> should throw IAE, which means MNAE is only appropriate as long as it
>> continues to subclass our surrogate for IAE - MIAE.
>>
>> If I sound hard-headed here, it would be great if someone could
>> explain to me what is different about null arguments at the point of
>> method activation in an API that explicitly disallows them. 
>> Consider, e.g. an empty array or array indices that will lead to
>> index out of bounds errors in APIs that take arrays.  What is so
>> different about null?  All are bad arguments violating API contract,
>> all detected at method activation time -> IAE.
> Okay, I'm going to lay out again the arguments (all which I know about were
> already mentioned in the thread).
> [I'll try to demonstrate that where we differ is on the usefulness of having
> a policy!]
>
> Taking quotes from your mail in reversed order:
>
>> All are bad arguments violating API contract,
>> all detected at method activation time -> IAE.
> Agreed... if the policy is to _always_ check for "null"!

I am only referring to APIs that explicitly disallow nulls.  I have
agreed that we will not always do this.  The specific case being
discussed here is an API that is going to include as an explicit
precondition that nulls are not allowed.  When this is done, what
should be thrown is an IllegalArgumentException, which for us means
some subclass of MathIllegalArgumentException.
>
> If we sometimes check and sometimes not, the thrown exception will be from a
> different hierarchy (NPE vs MathRuntimeException). This is annoying (and
> inconsistent).

That is an unfortunate consequence of not always checking.  I
understand that it may be impractical to always check.  Therefore,
some NPEs are going to be propagated to clients with no warning. 
>
> The oft-repeated issue is "Is it useful to check for null or not?"; at least
> 4 people answered "No", because this bug will never go unnoticed: sooner or
> later, using "null" _will_ raise exception. The sole and unique difference
> with CM checking and JVM checking is that the stack trace will (sometimes)
> be a little shorter in the former case.

And inferior first failure data capture and potential additional
computation, side effects or other unknown consequences (unless we
always think through the consequences of nulls propagated through
our code and make sure there are never any untoward side effects. 
All of these are reasons for the "when you must fail, fail fast and
loudly" maxim.  I understand that it may not be possible to adhere
to this fully in [math].

>  Most people have come to agree that
> it's not worth adopting a policy of thorough checking. [Rationale 1: users
> who encounter a NPE will need to inspect the stack trace and go to _their_
> code in order to see where _they_ put a "null". Rationale 2: there is
> probably a performance penalty to all these checks (especially in a well
> tested code where "null" reference bugs have been ironed out).]

The latter is a good point and why I am OK not checking everywhere.
>
>> Consider, e.g. an empty array or array indices that will lead to
>> index out of bounds errors in APIs that take arrays.  What is so
>> different about null?
> There is no difference... if there is a policy that decrees so.
>
> It is _not_ the policy of the JDK: "NullPointerException" is not the same
> error as "IndexOutOfBoundsException"; their common parent class is the
> (unspecific) "RuntimeException" and their sibling is
> "IllegalArgumentException".
> There is no "is-a" relationship between NPE, IOBE and IAE.

Here you are missing the point above - we are talking about specific
APIs that explicitly disallow nulls.  Just as we trap or check
arguments to avoid array index errors, we can in some cases do the
same for nulls.  In these cases, it is appropriate to throw IAE for
the nulls just as we do for the (avoided) AIOBE.
>
> Recalling that some 1.5 years ago you were against the adoption of the
> single exception hierarchy, rooted at "MathRuntimeException", in order to
> stay faithful to the JDK exception types, I wonder why you are on the
> opposite stand as NPE is concerned.

I am not.  I have agreed that we can go back to a common root.  But
that then forces us to create surrogates for the top level
exceptions such as IAE that the "math" versions used to subclass.  I
am OK with that.  But we should maintain the semantics correctly,
throwing a MIAE when API contracts are violated.
>
>> [...] what is different about null arguments at the point of
>> method activation in an API that explicitly disallows them.
> The difference is that there is no need to tell the user what the problem
> is because the raised exception says it all: "You tried to use a null
> reference." [As said above, the only issue is _when_ the exception is
> triggered.]
>
> The poli

Re: [VOTE] Release Commons Codec 1.7-RC2

[Thomas Neidhart]

On 09/11/2012 02:26 PM, Gary Gregory wrote:
> Hello All:
> 
> This is a VOTE to release Commons Codec 1.7-RC2.

+1

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CSV] Release status?

[sebb]

On 12 September 2012 13:25, Gary Gregory  wrote:
> On Wed, Sep 12, 2012 at 2:02 AM, Jörg Schaible
> wrote:
>
>> Hi Gary,
>>
>> Gary Gregory wrote:
>>
>> > Hi All:
>> >
>> > What left to be done to release a [CSV] 1.0?
>> >
>> > The one thing I do not like are all the CSVFoo and CSVBar class names. I
>> > like CsvFoo and CsvBar better.
>> >
>> > Any agreement (or objection) on changing that?
>>
>> Why? CSV is an acronym and as such capital letters are OK.
>>
>
> In general, IMO, no, an acronym should be a word in the camel-case context.
> The last letter of an all caps acronym merges with the first letter of the
> next word. Worse still is the case where more than one acronym follow each
> other.
>
> IMO, this is horrendous:
>
> IBMXMLDOMToSAXConverter
>
> This is much better:
>
> IbmXmlDomToSaxConverter
>
> When I see CSVParser, I see "CSVP" and then have to tease out that the last
> letter of is really the first letter of the next word. Lame.

I see Parser with a CSV prefix.

On the other hand, if I see CsvParser, at first I wonder what "Csv" means.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] About "NullArgumentException"

[Gilles Sadowski]

Hello.

[For those who don't wish to read the whole post, please at least go towards
the end and indicate your preferred option. Thanks.]

> > [...]
> >> All are bad arguments violating API contract,
> >> all detected at method activation time -> IAE.
> > Agreed... if the policy is to _always_ check for "null"!
> 
> I am only referring to APIs that explicitly disallow nulls.

I don't know what you mean by "only": Almost _all_ the API disallows "null".
What has "implicitly" or "explicitly" have to do with that (other than
"implicitly" being equivalent to lacking documentation vs "explicitly" being
defined by a default policy)?

>  I have
> agreed that we will not always do this.

Again, this is one point where we differ as regards to "rules". I contend
that there must be an "ideal", defined by the policy. Is the ideal to always
check or to never check. I think the latter, for the reasons explained.

The policy cannot be "sometimes yes, sometimes no" unless you can define in
which case to do it and in which not, which is clearly more complicated.

> The specific case being
> discussed here is an API that is going to include as an explicit
> precondition that nulls are not allowed.  When this is done, what
> should be thrown is an IllegalArgumentException, which for us means
> some subclass of MathIllegalArgumentException.

If we were to decide that the ideal is to always check (an obviously
different policy), I wouldn't have a problem with this.
What I point at is the potential burden on the _user_ if he wants to
intercept exceptions: for the _same_ problem (null reference), they'd have
to catch two types of exceptions: NPE vs NAE (as sublcass of MIAE).

If nobody cares about that, I won't either. I just wanted to stress that we
might have some user complaints about this inconsistency which will appear
at the contact point between user code and CM code: Because it is simply not
nice to report the same problem in different ways.

And because it is inconsistent, some future contributor will raise this
issue again: "Why do we check here and throw MIAE and why don't we check
there and let the JVM throw NPE?". [This is exactly what you reported about
checking the components of a FieldVector but not the vector itself.]

> >
> > If we sometimes check and sometimes not, the thrown exception will be from a
> > different hierarchy (NPE vs MathRuntimeException). This is annoying (and
> > inconsistent).
> 
> That is an unfortunate consequence of not always checking.  I
> understand that it may be impractical to always check.  Therefore,
> some NPEs are going to be propagated to clients with no warning. 

What do you mean by "impractical"?
In practice, we will not check everything tomorrow, but we can decide to
work toward that goal.
But we have to answer the question not of whether it is practical, but
whether it is desirable.
This is a quite simple issue; and I don't believe in considerations like
it might be good in some part of CM APIs but not in others. [In _principle_
I mean; I don't say that in _practice_ some parts of CM won't be up-to-date
sooner than other parts.]

> >
> > The oft-repeated issue is "Is it useful to check for null or not?"; at least
> > 4 people answered "No", because this bug will never go unnoticed: sooner or
> > later, using "null" _will_ raise exception. The sole and unique difference
> > with CM checking and JVM checking is that the stack trace will (sometimes)
> > be a little shorter in the former case.
> 
> And inferior first failure data capture and potential additional
> computation, side effects or other unknown consequences (unless we
> always think through the consequences of nulls propagated through
> our code and make sure there are never any untoward side effects. 
> All of these are reasons for the "when you must fail, fail fast and
> loudly" maxim.  I understand that it may not be possible to adhere
> to this fully in [math].

You repeat the mantra "fail fast, etc." but do not give a counter-argument
to mine about the NPE being as fast as it needs to be for this kind of
failure.
I'd like to see one example of "untoward side effects".

> >  Most people have come to agree that
> > it's not worth adopting a policy of thorough checking. [Rationale 1: users
> > who encounter a NPE will need to inspect the stack trace and go to _their_
> > code in order to see where _they_ put a "null". Rationale 2: there is
> > probably a performance penalty to all these checks (especially in a well
> > tested code where "null" reference bugs have been ironed out).]
> 
> The latter is a good point and why I am OK not checking everywhere.

The argument is equally valid _everywhere_ (unless you can provide the
above example), in both directions: either it is good to check, then it is
always good, or in some cases it is not necessary, then it is never
necessary.

> >
> >> Consider, e.g. an empty array or array indices that will lead to
> >> index out of bounds errors in APIs that take arrays.  What is s

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-dbcp has an issue affecting its community integration.
This issue affects 18 projects,
 and has been outstanding for 71 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp :  Object Pooling
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- jakarta-tomcat-4.0 :  Servlet 2.3 and JSP 1.2 Reference Implementation
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-dbcp :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers
- javax.el :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- javax.servlet :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation 
(for ...
- javax.servlet.jsp :  Java Servlet 2.5 & Server Pages JSP 2.1 
implementation (for ...
- solr :  Java Based Search Engine
- solr-test :  Java Based Search Engine
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- tomcat-tc7.0.x :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
...
- tomcat-tc7.0.x-dbcp :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-trunk :  Tomcat 8.x, a web server implementing Java Servlet 3.1,
...
- tomcat-trunk-dbcp :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...
- tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html
Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-13092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-13092012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar
-
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class DelegatingDatabaseMetaData extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61:
 error: DelegatingResultSet is not abstract and does not override abstract 
method getObject(String,Class) in ResultSet
[javac] public class DelegatingResultSet extends Aban

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 71 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 :  Database Connection Pool


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-13092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-13092012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
 error: BasicDataSource is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
 error: DelegatingStatement is not abstract and does not override abstract 
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements 
Statement {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
 error: DelegatingPreparedStatement is not abstract and does not override 
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
 error: DelegatingCallableStatement is not abstract and does not override 
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class

[GUMP@vmgump]: Project commons-exec-test (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-exec-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-exec-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html
Work Name: build_apache-commons_commons-exec-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 24 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
Running org.apache.commons.exec.util.StringUtilTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.exec.util.MapUtilTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.exec.DefaultExecutorTest
FOO..
gdal_translate
HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif
FOO..
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.035 ms
Process completed in 2007 millis; below is its output
Process timed out and was killed by watchdog.
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2003 millis; below is its output
Process timed out and was killed.
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Executing [sh, -c, src/test/scripts/invoker.sh]
invoker.sh -- going to start daemon process
invoker.sh --  daemon process was started
cd: 21: can't cd to ../../../target
Process completed in 8031 millis; above is its output
Processes terminated: 6 killed: 0 Multiplier: 1 MaxRetries: 180 Elapsed (avg 
ms): 1004
Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.751 sec <<< 
FAILURE!

Results :

Failed tests: 
  testExec_60(org.apache.commons.exec.DefaultExecutorTest)

Tests run: 95, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 23 seconds
[INFO] Finished at: Thu Sep 13 02:07:04 UTC 2012
[INFO] Final Memory: 28M/67M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1313092012, vmgump.apache.org:vmgump:1313092012
Gump E-mail Identifier (unique within run) #18.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 76 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 2 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1347508598080
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.a

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-chain2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 93 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-chain2 :  GoF "Chain of Responsibility" pattern


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project 
name
 -DEBUG- Sole pom output [pom.xml] identifier set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html
Work Name: build_apache-commons_commons-chain2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 59 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/chain]
M2_HOME: /opt/maven2
-
[INFO] Building war: 
/srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war
[INFO] 
[INFO] Building Apache Commons Chain :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT
2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 57 seconds
[INFO] Finished at: Thu Sep 13 05:09:31 UTC 2012
[INFO] Final Memory: 113M/241M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/atom.

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 76 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.326 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

Tests run: 179, Failures: 0, Errors: 1, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 16 seconds
[INFO] Finished at: Thu Sep 13 05:26:34 UTC 2012
[INFO] Final Memory: 25M/60M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml
- Atom: 
http://vmgump.apache.o

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

[Gump]

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 gene...@gump.apache.org.

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 71 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils :  Commons DbUtils


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to 
project name
 -INFO- Optional dependency mockito failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.pom
1K downloaded  (mockito-core-1.9.0.pom)
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded  (hamcrest-all-1.1.pom)
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded  (hamcrest-all-1.1.jar)
1381K downloaded  (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks

main:
 [copy] Copying 2 files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1347514333699
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 28 source files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 

[math] Documenting exceptions in interfaces (MATH-854)

[Sébastien Brisard]

Dear all,
in previous discussions, it was decided that Interfaces (and, I
suppose abstract methods) should *not* have a throws clause.
So, yesterday, I started modifying the javadoc of FieldVector. Each
"throws" clause was simply replaced by the following statement
"Implementations should throw [...] if [...]". Please have a look to
FieldVector and ArrayFieldVector for clarity.
This has several drawbacks

1. The javadoc of implementations must grow, since the implementer
must write something like

/**
 * {@inheritDoc}
 *
 * @throws DimensionMismatchException if {@code v} is not the same size as
 * {@code this}.
 */

instead of simply writing /** {@inheritDoc} */.

2. The resulting javadoc of implementations is not satisfactory. For
example, the javadoc of FieldVector.add(FieldVecto v) now reads

// Begin Javadoc
Compute the sum of this and v. Implementations should throw
DimensionMismatchException if v is not the same size as this.

Specified by:
add in interface FieldVector>
Parameters:
v - vector to be added
Returns:
this + v
Throws:
DimensionMismatchException - if v is not the same size as this.
// End javadoc

The "should throw" statement should really not be here, but it is too
much of a hassle to rewrite the whole javadoc comment for each
implementation.

3. Using Luc's trick brings a whole lot of error messages

// Begin error message
Exception MathXxxException is not compatible with throws clause in [...]
// End error message

this is not really a problem, but it makes the whole process of
populating the throws clauses a bit difficult.

4. More importantly, there is *no way* to ensure that we actually
document all exceptions. Indeed, if we take for example
FieldVector.mapDivide(T d)

The only reason we know we *have* to add MathArithmeticException to
the throws clause is because FieldElement (which is an interface)
*specifies* this exception in the throws clause of
FieldElement.divide().
If this throws clause is removed from interfaces, then LUC'S TRICK
becomes useless. [1]

For all these reasons, I would advocate *specifying* in interfaces
exceptions which we know must occur. For example,
DimensionMismatchException will be in the signature of *all*
implementations of FieldVector.add(FieldVector). Why not add it to the
throws clause? The answer is likely to be "because it is bad
practice", but I think advertising unchecked exceptions is already a
bad practice. So I think if we go for a bad practice anyway, we should
do it *only if it makes our lives easier*. I don't think the current
state does.

On a more personal side, I'd like to say that I'm getting tired of
this issue. I have been working for days on the linear package, but
I'm making no progress, because each time I commit a change, I realize
this was not the proper thing to do because of new exchanges on the
ML. So I keep going back and forth. This is really sucking all of my
C-M time, while I'd like to be working on other issues (eg special
functions Gamma and Beta, visitors for FieldVectors, ...). That would
be perfectly fine if I could see the benefit of MATH-854. While this
seemed a good idea when we started discussing it, I'm not sure
anymore, now that we have really tried to implement MATH-854.

I'm sure that I'm not the only one among the regular developers to
spend so much time on this issue. Our powers are limited, and I really
would rather we had more time to concentrate on real (meaning,
numerical) issues.

Sébastien

[1] MathArithmeticException in FieldElement.divide(FieldElement) is
probably not the best example, as Gilles noted inconsistencies
(Decimal64 and Complex do not throw an exception, but return NaN
instead).


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org