[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at 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 50 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: 18 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.004 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 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.019 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.02 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.163 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 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: 14 seconds [INFO] Finished at: Sun May 01 07:01:57 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
[RESULT][VOTE] Release Apache Commons Discovery 0.5-RC2
Hi all, this vote has passed with five +1 binding votes from following [commons] PMCs: Oliver Heger Jörg Schaible Henri Yandell Simone Tripodi Phil Steitz I'm going to proceed to next steps, thanks everybody who took part to the release process!!! Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 12:26 AM, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/11 3:02 PM, Simone Tripodi wrote: Hi Phil, thanks for reviewing, very appreciated! 0) is it fine fixing these warning for the current SNAPSHOT? Yes, that is what I meant by not a showstopper. I am +1 on releasing as is. 1) indeed, they have been generated by the release-plugin. How do we manage this situation? Do we update them manually before/after tagging the release? I don't think there is anything that can be done about it. You definitely do not want to mess with the tag since then the release will not correspond to the tag. This also is not a showstopper. Phil Many thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Apr 30, 2011 at 11:31 PM, Phil Steitz phil.ste...@gmail.com wrote: On 4/27/11 12:38 PM, Simone Tripodi wrote: Hi all guys! After the failed RC1, I'm here to propose a new Apache Commons-DIscovery release, based on RC2, please cast your votes! Many thanks in advance to everybody will take part to the vote process :) All the best, Simo Release notes: http://people.apache.org/builds/commons/discovery/0.5/RC2/RELEASE-NOTES.txt Tag: http://svn.apache.org/repos/asf/commons/proper/discovery/tags/DISCOVERY_0_5_RC2/ Site: http://people.apache.org/builds/commons/discovery/0.5/RC2/site/ Binaries: http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/commons-discovery/commons-discovery/0.5/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org +1 Verified sigs and hashes and tested build with JDK 1.6.0_24 Small non-show-stopping nits: 0) lots of findbugs warnings - none look like real bugs to me, but they should be documented and excluded in findbugs config 1) release pom has wrong scm connection info (this is an artifact of using the release plugin AIUI) Phil - 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 - 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] Restoring IAE to MathUtils#binomialCoefficient methods
On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote: On 4/30/11 4:33 PM, Gilles Sadowski wrote: On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote: Converting some of my code to use trunk, I discovered that the binomialCoefficient methods no longer throw IllegalArgumentException when parameters are invalid. The consensus was a singly rooted hierarchy (MathRuntimeException). The advantage being commonly agreed on was to offer the map functionality for adding messages and context information. I guess I misunderstood and after really seeing the consequences in my own code, I am going to have to ask that we reopen that discussion - i.e., I would like us to throw IAE and other standard exceptions where appropriate, as in this case, as we have up to and through 2.2. I know I said before that I did not see this as worth arguing about, but I really think this change is a bad API design decision that will cause needless hassle and surprising RTEs for users upgrading to the new version. I'm astonished, and for the time being, will refrain from other comments. The javadoc asserts that MathIllegalArgumentException will be thrown in these cases, but that is not correct, I don't understand; the code for checkBinomial can throw NumberIsTooLargeException or NotPositiveException and they are subclasses of MathIllegalArgumentException. Sorry. my mistake. since what is actually thrown now can differ depending on the parameter problem That's a feature, naturally: Different problem, different exception. That's where I disagree. I see zero value added and in fact confusing complexity introduced by these exceptions. When you ask for B(n,k) where k is not less than or equal to n, a standard IAE with a message that says precisely that (which the current message does) is clear and *better* that a NumberIsTooLargeException. What number? I guess it must be k? To figure it out you have to look at the exception message, which is *exactly the same message* that the old code reported. If we really think we need to specialize and report different exceptions for every precondition violation (which I do not agree with), then these exceptions should be meaningful in the context of the API that is using them. So here, for example, we would have to throw something like CombinationSizeTooLargeForSetException. Then, we do _not_ disagree _now_. From the start, I stated that a consistent design would be to define a specific exception for each specific that must be reported, especially if it must contain complex functionality like localization. IIRC, either you or Luc (or both) did not want a large number of exceptions. To keep the number down, we reuse less specific exception types (like NumberIsTooLargeException in several contexts) and rely on the message(s) for context information. Nothing lost from the previous situation (when one *had* to rely solely on the message)! To answer your question above: No, you don't have to guess which number is too large; there is an accessor getArgument() that returns the number that triggered the exception and another getMax() that informs you about the maximum allowed number. and the resulting exceptions are neither standard IAEs nor descendents of MathIAE. From what I see, they are descendents of MathIAE. I have patched the code to return a standard IAE (with localized message). Per discussion in [1] it looks like we were close to consensus to favor standard exceptions and in this case, No, that thread was discussing throwing standard NullPointerException vs throwing a CM-specific NullArgumentException (subtype of MathIAE) vs not checking for null pointer at all. [I don't think that a consensus has been reached on that issue.] For all the other cases of invalid parameters passed to methods, it had been settled already that MathIllegalArgumentException (or subclasses thereof) would been thrown. I would much rather return a standard IAE with meaningful error message rather than a non-standard RTE (with exactly the same error message and generally confusing type - e.g. NumberIsTooSmall when n, k parameters are not in the right order) and keep the javadoc simple. Otherwise, the main method javadoc has to be rewritten to conform to what the code now does. The Javadoc @throws tag is not incorrect: - * @throws MathIllegalArgumentException if preconditions are not met - But it is not as precise as it could (by mentioning the types actually thrown by checkBinomial). The main description is indeed a remnant of the old behaviour and it is yet another proof that it is not good documentation practise to repeat the (supposedly) same information several times. Documentation for methods binomialCoefficientDouble and binomialCoefficientLog also refer to the old behaviour and must be updated. Regardless of how we settle this, we *must* keep
[release process] zip and tar.gz included in maven repo?
Hi all guys, while copying maven artifacts as described in the wiki page[1] using the command below, I noticed .zip and .tar.gz artifacts are included :/ Is this right? I wouldn't say 'no' but maybe I missed something. Moreover, the command doesn't work with M3 because the missing wagon-ssh extension. Do you have any suggestion to complete correctly the release process? Thanks in advance! Simo mvn stage:copy -Dsource=http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/; \ -Dtarget=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository \ -DtargetRepositoryId=apache.releases \ -Dversion=0.5 [1] http://wiki.apache.org/commons/CreatingReleases (see E.2 Copy Artifacts from Staging) http://people.apache.org/~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: [release process] zip and tar.gz included in maven repo?
Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo [1] http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 12:38 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, while copying maven artifacts as described in the wiki page[1] using the command below, I noticed .zip and .tar.gz artifacts are included :/ Is this right? I wouldn't say 'no' but maybe I missed something. Moreover, the command doesn't work with M3 because the missing wagon-ssh extension. Do you have any suggestion to complete correctly the release process? Thanks in advance! Simo mvn stage:copy -Dsource=http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/; \ -Dtarget=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository \ -DtargetRepositoryId=apache.releases \ -Dversion=0.5 [1] http://wiki.apache.org/commons/CreatingReleases (see E.2 Copy Artifacts from Staging) http://people.apache.org/~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: [release process] zip and tar.gz included in maven repo?
Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Restoring IAE to MathUtils#binomialCoefficient methods
On Sun, May 01, 2011 at 12:48:14PM +0200, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote:
On 4/30/11 4:33 PM, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote:
Converting some of my code to use trunk, I discovered that the
binomialCoefficient methods no longer throw IllegalArgumentException
when parameters are invalid.
The consensus was a singly rooted hierarchy (MathRuntimeException).
The advantage being commonly agreed on was to offer the map
functionality
for adding messages and context information.
I guess I misunderstood and after really seeing the consequences in
my own code, I am going to have to ask that we reopen that
discussion - i.e., I would like us to throw IAE and other standard
exceptions where appropriate, as in this case, as we have up to and
through 2.2. I know I said before that I did not see this as worth
arguing about, but I really think this change is a bad API design
decision that will cause needless hassle and surprising RTEs for
users upgrading to the new version.
I'm astonished, and for the time being, will refrain from other comments.
There is no one single best API design. What counts most IMO is that it is
consistent and leads to clean and lean code.
The old exception factories à la
-
MathRuntimeException.createIllegalArgumentException(Error with an argument
{0}, x);
-
failed on all accounts.
Now, I would like to settle this issue once for all. Should all CM
exceptions inherit from the standard Java exceptions hierarchies (rooted at
IAE, UOE, NPE, AE, etc.)? Although it had been answered no previously, it
was not my preferred choice. I could make it yes now but I'd rather not
changed that back and forth again and again.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Restoring IAE to MathUtils#binomialCoefficient methods
Le 01/05/2011 15:00, Gilles Sadowski a écrit :
On Sun, May 01, 2011 at 12:48:14PM +0200, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote:
On 4/30/11 4:33 PM, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote:
Converting some of my code to use trunk, I discovered that the
binomialCoefficient methods no longer throw IllegalArgumentException
when parameters are invalid.
The consensus was a singly rooted hierarchy (MathRuntimeException).
The advantage being commonly agreed on was to offer the map functionality
for adding messages and context information.
I guess I misunderstood and after really seeing the consequences in
my own code, I am going to have to ask that we reopen that
discussion - i.e., I would like us to throw IAE and other standard
exceptions where appropriate, as in this case, as we have up to and
through 2.2. I know I said before that I did not see this as worth
arguing about, but I really think this change is a bad API design
decision that will cause needless hassle and surprising RTEs for
users upgrading to the new version.
I'm astonished, and for the time being, will refrain from other comments.
There is no one single best API design. What counts most IMO is that it is
consistent and leads to clean and lean code.
The old exception factories à la
-
MathRuntimeException.createIllegalArgumentException(Error with an argument
{0}, x);
-
failed on all accounts.
Now, I would like to settle this issue once for all.
Agreed.
Should all CM
exceptions inherit from the standard Java exceptions hierarchies (rooted at
IAE, UOE, NPE, AE, etc.)? Although it had been answered no previously, it
was not my preferred choice.
Choose as you want. I won't voice any opinion here.
I could make it yes now but I'd rather not
changed that back and forth again and again.
Agreed.
Luc
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: [release process] zip and tar.gz included in maven repo?
Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - 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: [release process] zip and tar.gz included in maven repo?
Moreover, after 4 hours the central has not been synched yet... are you aware of any issue? Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi simonetrip...@apache.org wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - 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] Restoring IAE to MathUtils#binomialCoefficient methods
On 5/1/11 3:48 AM, Gilles Sadowski wrote: On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote: On 4/30/11 4:33 PM, Gilles Sadowski wrote: On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote: Converting some of my code to use trunk, I discovered that the binomialCoefficient methods no longer throw IllegalArgumentException when parameters are invalid. The consensus was a singly rooted hierarchy (MathRuntimeException). The advantage being commonly agreed on was to offer the map functionality for adding messages and context information. I guess I misunderstood and after really seeing the consequences in my own code, I am going to have to ask that we reopen that discussion - i.e., I would like us to throw IAE and other standard exceptions where appropriate, as in this case, as we have up to and through 2.2. I know I said before that I did not see this as worth arguing about, but I really think this change is a bad API design decision that will cause needless hassle and surprising RTEs for users upgrading to the new version. I'm astonished, and for the time being, will refrain from other comments. The javadoc asserts that MathIllegalArgumentException will be thrown in these cases, but that is not correct, I don't understand; the code for checkBinomial can throw NumberIsTooLargeException or NotPositiveException and they are subclasses of MathIllegalArgumentException. Sorry. my mistake. since what is actually thrown now can differ depending on the parameter problem That's a feature, naturally: Different problem, different exception. That's where I disagree. I see zero value added and in fact confusing complexity introduced by these exceptions. When you ask for B(n,k) where k is not less than or equal to n, a standard IAE with a message that says precisely that (which the current message does) is clear and *better* that a NumberIsTooLargeException. What number? I guess it must be k? To figure it out you have to look at the exception message, which is *exactly the same message* that the old code reported. If we really think we need to specialize and report different exceptions for every precondition violation (which I do not agree with), then these exceptions should be meaningful in the context of the API that is using them. So here, for example, we would have to throw something like CombinationSizeTooLargeForSetException. Then, we do _not_ disagree _now_. From the start, I stated that a consistent design would be to define a specific exception for each specific that must be reported, especially if it must contain complex functionality like localization. IIRC, either you or Luc (or both) did not want a large number of exceptions. To keep the number down, we reuse less specific exception types (like NumberIsTooLargeException in several contexts) and rely on the message(s) for context information. Nothing lost from the previous situation (when one *had* to rely solely on the message)! But in this case, my opinion is that IAE is just fine - there is nothing more specific to communicate unless you want to define something meaningful in the context of the API. NumberIsTooLarge has no value here. As I said, if we feel we need to make this particular exception due to precondition violation more precise, we would need to define an exception that refers to subset relation size or somesuch, which I don't see as necessary or valuable. To answer your question above: No, you don't have to guess which number is too large; there is an accessor getArgument() that returns the number that triggered the exception and another getMax() that informs you about the maximum allowed number. No, all that is reported is the *value*. To make this actually work, you would have to do something like store and report the formal parameter name. I don't see the point in this in general and certainly not in this case, as what is problematic is the order relation among the two parameters - not one is too small or the other is too large but that they violate the stated preconditions of the method. and the resulting exceptions are neither standard IAEs nor descendents of MathIAE. From what I see, they are descendents of MathIAE. I have patched the code to return a standard IAE (with localized message). Per discussion in [1] it looks like we were close to consensus to favor standard exceptions and in this case, No, that thread was discussing throwing standard NullPointerException vs throwing a CM-specific NullArgumentException (subtype of MathIAE) vs not checking for null pointer at all. [I don't think that a consensus has been reached on that issue.] For all the other cases of invalid parameters passed to methods, it had been settled already that MathIllegalArgumentException (or subclasses thereof) would been thrown. I would much rather return a standard IAE with meaningful error message rather than a non-standard RTE (with exactly the same
Re: [math] Restoring IAE to MathUtils#binomialCoefficient methods
On 5/1/11 6:00 AM, Gilles Sadowski wrote:
On Sun, May 01, 2011 at 12:48:14PM +0200, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote:
On 4/30/11 4:33 PM, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote:
Converting some of my code to use trunk, I discovered that the
binomialCoefficient methods no longer throw IllegalArgumentException
when parameters are invalid.
The consensus was a singly rooted hierarchy (MathRuntimeException).
The advantage being commonly agreed on was to offer the map functionality
for adding messages and context information.
I guess I misunderstood and after really seeing the consequences in
my own code, I am going to have to ask that we reopen that
discussion - i.e., I would like us to throw IAE and other standard
exceptions where appropriate, as in this case, as we have up to and
through 2.2. I know I said before that I did not see this as worth
arguing about, but I really think this change is a bad API design
decision that will cause needless hassle and surprising RTEs for
users upgrading to the new version.
I'm astonished, and for the time being, will refrain from other comments.
There is no one single best API design. What counts most IMO is that it is
consistent and leads to clean and lean code.
The old exception factories à la
-
MathRuntimeException.createIllegalArgumentException(Error with an argument
{0}, x);
-
failed on all accounts.
Now, I would like to settle this issue once for all. Should all CM
exceptions inherit from the standard Java exceptions hierarchies (rooted at
IAE, UOE, NPE, AE, etc.)? Although it had been answered no previously, it
was not my preferred choice. I could make it yes now but I'd rather not
changed that back and forth again and again.'
I apologize sincerely for opening this up again. I don't think
*all* exceptions thrown by [math] should derive from standard
exceptions, other than I guess Exception itself. I do think,
however, that [math] *should* throw standard exceptions directly
when appropriate and in general favor standard exceptions. In
particular, I would prefer that we revert to the 1.0-2.2 behavior of
throwing IllegalArgumentException when preconditions are violated.
I personally have no problem with using the exception factories and
will volunteer to retrofit the code if we can agree to this change.
Once again, I hate to flip-flop, but this is an important and
impactful decision and I have now experienced the upgrade pain
(unexpected RTEs when upgrading) directly so would like to ask that
we revisit it.
To be clear, my opinion is that for all of the RTEs currently
generated by MathRuntimeException.createXxxException, we should
generate and throw these exceptions directly, as appropriate, using
the factory to enable localization.
Phil
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: [release process] zip and tar.gz included in maven repo?
On 5/1/11 7:58 AM, Simone Tripodi wrote: Moreover, after 4 hours the central has not been synched yet... are you aware of any issue? It often takes quite a while, but it looks like commons-discovery may not have yet been synched from m2-ibiblio-rsych, so you may need to send a request to repository@ to get it set up for rsynch. I would wait a few more hours and then do that. Phil Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi simonetrip...@apache.org wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [release process] zip and tar.gz included in maven repo?
On 5/1/11 6:55 AM, Simone Tripodi wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? Thanks in advance, Simo I assume they have been *copied* not moved, right? So there is no risk in deleting them? In that case, you can just ssh to p.a.o and then delete the files manually from /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/ Let me know if you have problems and I will to this. I didn't want to do the deletes myself until you confirmed that what you / the plugin did was a copy so you still have the originals to move to dist/ somewhere. Phil http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [release process] zip and tar.gz included in maven repo?
On 5/1/11 6:55 AM, Simone Tripodi wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? I just tried to move the zips and tarballs to my home directory, but could not because the files were not group writeable This may also cause problems for the rsynch. You need to log into p.a.o and then cd /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/ chmod g+w * Then either delete or move the zips, tarballs and associated hashes and sigs. Phil Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: Incubator PMC/Board report for May 2011 (u...@commons.apache.org)
I just moderated this through to the user list. I don't know how this works in Incubator-land, but I would expect these messages to come to this list. Phil Original Message Subject:Incubator PMC/Board report for May 2011 (u...@commons.apache.org) Date: Sun, 1 May 2011 14:00:11 + (UTC) From: no-re...@apache.org Reply-To: Commons Users List u...@commons.apache.org To: u...@commons.apache.org Dear OGNL Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Thurs, 19 May 2011, 10 am Pacific. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/May2011 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [release process] zip and tar.gz included in maven repo?
Thanks *a lot* Phil for your kind help. I just executed the commands you suggested me, and dopped *tar.gz* *zip* files, original are still on staged[1] repository Looking forward to see Discovery synched!!! Have a nice day, Simo [1] http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/commons-discovery/commons-discovery/0.5/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 6:04 PM, Phil Steitz phil.ste...@gmail.com wrote: On 5/1/11 6:55 AM, Simone Tripodi wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? I just tried to move the zips and tarballs to my home directory, but could not because the files were not group writeable This may also cause problems for the rsynch. You need to log into p.a.o and then cd /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/ chmod g+w * Then either delete or move the zips, tarballs and associated hashes and sigs. Phil Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - 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 - 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: [release process] zip and tar.gz included in maven repo?
On 5/1/11 9:18 AM, Simone Tripodi wrote: Thanks *a lot* Phil for your kind help. I just executed the commands you suggested me, and dopped *tar.gz* *zip* files, original are still on staged[1] repository Looking forward to see Discovery synched!!! Have a nice day, Simo [1] http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/commons-discovery/commons-discovery/0.5/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ Great. Files and perms look good. If the synch still have not happened in a few more hours, ping repository@ Phil On Sun, May 1, 2011 at 6:04 PM, Phil Steitz phil.ste...@gmail.com wrote: On 5/1/11 6:55 AM, Simone Tripodi wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? I just tried to move the zips and tarballs to my home directory, but could not because the files were not group writeable This may also cause problems for the rsynch. You need to log into p.a.o and then cd /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/ chmod g+w * Then either delete or move the zips, tarballs and associated hashes and sigs. Phil Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Incubator PMC/Board report for May 2011 (u...@commons.apache.org)
Thanks a lot Phil, I'll start filling the report since we just joined the incubator with OGNL component :P I think Christian can help with MLs settings. Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 6:08 PM, Phil Steitz phil.ste...@gmail.com wrote: I just moderated this through to the user list. I don't know how this works in Incubator-land, but I would expect these messages to come to this list. Phil Original Message Subject: Incubator PMC/Board report for May 2011 (u...@commons.apache.org) Date: Sun, 1 May 2011 14:00:11 + (UTC) From: no-re...@apache.org Reply-To: Commons Users List u...@commons.apache.org To: u...@commons.apache.org Dear OGNL Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Thurs, 19 May 2011, 10 am Pacific. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/May2011 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - 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: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3 JDK 1.5 rebuild)
Except for the test failure I reported in another thread everything looks good. If my assumptions are correct, only users with a German default locale who want to build the source distribution with Java 1.5 will be hit by the problem. Probably you are right that this is not a release blocker. So here is my +1. Oliver Am 30.04.2011 02:58, schrieb Henri Yandell: [Repeating now that I've rebuilt the artifacts using Java 1.5] = Lang is ready to consider 3.0 release again. RC3 is available here: http://people.apache.org/~bayard/commons-lang3-3.0-RC3/ Maven artifacts: http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/ Website: http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/ Note that there is a 2.6-3.0 Clirr report in the site that may prove useful: http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html This vote will close no sooner than in 72 hours time, 0300 GMT 3-May 2011. [ ] +1 [ ] -1, with reason Hen - 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] Restoring IAE to MathUtils#binomialCoefficient methods
On Sun, May 01, 2011 at 08:11:00AM -0700, Phil Steitz wrote: On 5/1/11 3:48 AM, Gilles Sadowski wrote: On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote: On 4/30/11 4:33 PM, Gilles Sadowski wrote: On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote: Converting some of my code to use trunk, I discovered that the binomialCoefficient methods no longer throw IllegalArgumentException when parameters are invalid. The consensus was a singly rooted hierarchy (MathRuntimeException). The advantage being commonly agreed on was to offer the map functionality for adding messages and context information. I guess I misunderstood and after really seeing the consequences in my own code, I am going to have to ask that we reopen that discussion - i.e., I would like us to throw IAE and other standard exceptions where appropriate, as in this case, as we have up to and through 2.2. I know I said before that I did not see this as worth arguing about, but I really think this change is a bad API design decision that will cause needless hassle and surprising RTEs for users upgrading to the new version. I'm astonished, and for the time being, will refrain from other comments. The javadoc asserts that MathIllegalArgumentException will be thrown in these cases, but that is not correct, I don't understand; the code for checkBinomial can throw NumberIsTooLargeException or NotPositiveException and they are subclasses of MathIllegalArgumentException. Sorry. my mistake. since what is actually thrown now can differ depending on the parameter problem That's a feature, naturally: Different problem, different exception. That's where I disagree. I see zero value added and in fact confusing complexity introduced by these exceptions. When you ask for B(n,k) where k is not less than or equal to n, a standard IAE with a message that says precisely that (which the current message does) is clear and *better* that a NumberIsTooLargeException. What number? I guess it must be k? To figure it out you have to look at the exception message, which is *exactly the same message* that the old code reported. If we really think we need to specialize and report different exceptions for every precondition violation (which I do not agree with), then these exceptions should be meaningful in the context of the API that is using them. So here, for example, we would have to throw something like CombinationSizeTooLargeForSetException. Then, we do _not_ disagree _now_. From the start, I stated that a consistent design would be to define a specific exception for each specific that must be reported, especially if it must contain complex functionality like localization. IIRC, either you or Luc (or both) did not want a large number of exceptions. To keep the number down, we reuse less specific exception types (like NumberIsTooLargeException in several contexts) and rely on the message(s) for context information. Nothing lost from the previous situation (when one *had* to rely solely on the message)! But in this case, my opinion is that IAE is just fine - there is nothing more specific to communicate unless you want to define something meaningful in the context of the API. NumberIsTooLarge has no value here. I don't agree. This is the concept that describes the problem: indeed, the precondition is that k must be smaller than n. This has the same value as the out of range concept where you give the value of some parameter and the values of the bounds. As I said, if we feel we need to make this particular exception due to precondition violation more precise, we would need to define an exception that refers to subset relation size or somesuch, which I don't see as necessary or valuable. In principle, I've nothing against devising a deeper hierarchy that would make the type of the exception refer to the exact problem. However, there would indeed be not much practical value added if all use cases are about letting the exception bubble upwards until it aborts the program (at which point a human will read the error mesage). To answer your question above: No, you don't have to guess which number is too large; there is an accessor getArgument() that returns the number that triggered the exception and another getMax() that informs you about the maximum allowed number. No, all that is reported is the *value*. Well, of course: CM is a numerical library, not a symbolic one. To make this actually work, you would have to do something like store and report the formal parameter name. I don't see the point in this in general Me neither. and certainly not in this case, as what is problematic is the order relation among the two parameters - not one is too small or the other is too large but that they violate the stated preconditions of the method. I really don't understand what bothers you! The precondition k = n means
Re: [math] Restoring IAE to MathUtils#binomialCoefficient methods
On Sun, May 01, 2011 at 08:34:31AM -0700, Phil Steitz wrote:
On 5/1/11 6:00 AM, Gilles Sadowski wrote:
On Sun, May 01, 2011 at 12:48:14PM +0200, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote:
On 4/30/11 4:33 PM, Gilles Sadowski wrote:
On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote:
Converting some of my code to use trunk, I discovered that the
binomialCoefficient methods no longer throw IllegalArgumentException
when parameters are invalid.
The consensus was a singly rooted hierarchy (MathRuntimeException).
The advantage being commonly agreed on was to offer the map
functionality
for adding messages and context information.
I guess I misunderstood and after really seeing the consequences in
my own code, I am going to have to ask that we reopen that
discussion - i.e., I would like us to throw IAE and other standard
exceptions where appropriate, as in this case, as we have up to and
through 2.2. I know I said before that I did not see this as worth
arguing about, but I really think this change is a bad API design
decision that will cause needless hassle and surprising RTEs for
users upgrading to the new version.
I'm astonished, and for the time being, will refrain from other comments.
There is no one single best API design. What counts most IMO is that it is
consistent and leads to clean and lean code.
The old exception factories à la
-
MathRuntimeException.createIllegalArgumentException(Error with an
argument {0}, x);
-
failed on all accounts.
Now, I would like to settle this issue once for all. Should all CM
exceptions inherit from the standard Java exceptions hierarchies (rooted at
IAE, UOE, NPE, AE, etc.)? Although it had been answered no previously, it
was not my preferred choice. I could make it yes now but I'd rather not
changed that back and forth again and again.'
I apologize sincerely for opening this up again. I don't think
*all* exceptions thrown by [math] should derive from standard
exceptions, other than I guess Exception itself. I do think,
however, that [math] *should* throw standard exceptions directly
when appropriate and in general favor standard exceptions. In
particular, I would prefer that we revert to the 1.0-2.2 behavior of
throwing IllegalArgumentException when preconditions are violated.
I personally have no problem with using the exception factories and
will volunteer to retrofit the code if we can agree to this change.
We agreed to provide enhanced context-enabled exceptions as a feature to
users. Throwing plain standard exceptions contradicts that goal.
I propose to rework the hierarchies so that MathIAE will inherit from the
standard IAE. This will solve the annoyance you would have had when
upgrading your code. [And we'll keep the addMessage feature together with
accessors like getArgument and getMax etc.]
The exception factories were a bad design idea (IMHO of course; plenty of
arguments given elsewhere in the last 6-8 months). One of the goals of the
exceptions refactoring was to get rid of them.
Once again, I hate to flip-flop, but this is an important and
impactful decision and I have now experienced the upgrade pain
(unexpected RTEs when upgrading) directly so would like to ask that
we revisit it.
Not unexpected RTEs. Incompatibilities are to be expected.
Anyways, this won't happen with the new-new solution.
To be clear, my opinion is that for all of the RTEs currently
generated by MathRuntimeException.createXxxException, we should
generate and throw these exceptions directly, as appropriate, using
the factory to enable localization.
No, I like the current design; I didn't like the one you want to revert to.
Consistency implies that *all* exceptions thrown from CM must behave the
same way. I thus propose to add an interface like (maybe a better name?):
---
interface ContextedException {
void addMessage(Localizable pattern,
Object ... arguments);
void setContext(String key, Object value);
Object getContext(String key);
SetString getContextKeys();
String getMessage(final Locale locale);
String getMessage(final Locale locale,
final String separator);
}
And all CM exceptions will implement this interface. [Instead of
automatically inheriting the behaviour by being subclasses of
MathRuntimeException.]
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Restoring IAE to MathUtils#binomialCoefficient methods
On 5/1/11 2:29 PM, Gilles Sadowski wrote: On Sun, May 01, 2011 at 08:11:00AM -0700, Phil Steitz wrote: On 5/1/11 3:48 AM, Gilles Sadowski wrote: On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote: On 4/30/11 4:33 PM, Gilles Sadowski wrote: On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote: Converting some of my code to use trunk, I discovered that the binomialCoefficient methods no longer throw IllegalArgumentException when parameters are invalid. The consensus was a singly rooted hierarchy (MathRuntimeException). The advantage being commonly agreed on was to offer the map functionality for adding messages and context information. I guess I misunderstood and after really seeing the consequences in my own code, I am going to have to ask that we reopen that discussion - i.e., I would like us to throw IAE and other standard exceptions where appropriate, as in this case, as we have up to and through 2.2. I know I said before that I did not see this as worth arguing about, but I really think this change is a bad API design decision that will cause needless hassle and surprising RTEs for users upgrading to the new version. I'm astonished, and for the time being, will refrain from other comments. The javadoc asserts that MathIllegalArgumentException will be thrown in these cases, but that is not correct, I don't understand; the code for checkBinomial can throw NumberIsTooLargeException or NotPositiveException and they are subclasses of MathIllegalArgumentException. Sorry. my mistake. since what is actually thrown now can differ depending on the parameter problem That's a feature, naturally: Different problem, different exception. That's where I disagree. I see zero value added and in fact confusing complexity introduced by these exceptions. When you ask for B(n,k) where k is not less than or equal to n, a standard IAE with a message that says precisely that (which the current message does) is clear and *better* that a NumberIsTooLargeException. What number? I guess it must be k? To figure it out you have to look at the exception message, which is *exactly the same message* that the old code reported. If we really think we need to specialize and report different exceptions for every precondition violation (which I do not agree with), then these exceptions should be meaningful in the context of the API that is using them. So here, for example, we would have to throw something like CombinationSizeTooLargeForSetException. Then, we do _not_ disagree _now_. From the start, I stated that a consistent design would be to define a specific exception for each specific that must be reported, especially if it must contain complex functionality like localization. IIRC, either you or Luc (or both) did not want a large number of exceptions. To keep the number down, we reuse less specific exception types (like NumberIsTooLargeException in several contexts) and rely on the message(s) for context information. Nothing lost from the previous situation (when one *had* to rely solely on the message)! But in this case, my opinion is that IAE is just fine - there is nothing more specific to communicate unless you want to define something meaningful in the context of the API. NumberIsTooLarge has no value here. I don't agree. This is the concept that describes the problem: indeed, the precondition is that k must be smaller than n. This has the same value as the out of range concept where you give the value of some parameter and the values of the bounds. No, it is actually a different concept. In mathematical terms, it is a binary relation that is failing here: k n. What NumberIsTooLarge (or NumberIsTooSmall which could also be applied here, to n instead of k) conveys is unary. As I said, if we feel we need to make this particular exception due to precondition violation more precise, we would need to define an exception that refers to subset relation size or somesuch, which I don't see as necessary or valuable. In principle, I've nothing against devising a deeper hierarchy that would make the type of the exception refer to the exact problem. However, there would indeed be not much practical value added if all use cases are about letting the exception bubble upwards until it aborts the program (at which point a human will read the error mesage). Sounds like you are arguing here to just leave it as IAE, which is fine by me. To answer your question above: No, you don't have to guess which number is too large; there is an accessor getArgument() that returns the number that triggered the exception and another getMax() that informs you about the maximum allowed number. No, all that is reported is the *value*. Well, of course: CM is a numerical library, not a symbolic one. To make this actually work, you would have to do something like store and report the formal parameter name. I don't see the point in this in general Me
[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at 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 230 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: 17 secs Command Line: /opt/maven2/bin/mvn --batch-mode --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 - --- T E S T S --- Running org.apache.commons.scxml.invoke.InvokeTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.337 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.208 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.857 sec FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.343 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.13 sec FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.324 sec Results : Failed tests: testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest) testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest) Tests run: 228, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/scxml/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: Mon May 02 04:44:40 UTC 2011 [INFO] Final Memory: 25M/61M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 0902052011, vmgump.apache.org:vmgump:0902052011 Gump E-mail Identifier (unique within
