[GUMP@vmgump]: Project commons-jelly-tags-sql (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at 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 51 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-03092012.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: Mon Sep 03 07:03:17 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 1303092012, vmgump.apache.org:vmgump:1303092012
Gump E-mail Identifier (unique within run) #62.
--
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: commons-lang pull request: Update src/main/java/org/apache/commons/lang3/Sy...
Cool to have a patch come in via github. Bear in mind there's nothing to suggest Olloth is on the mailing list. Hen On Sat, Sep 1, 2012 at 6:16 PM, James Carman wrote: > Can you submit a JIRA and attach a SVN patch please? > > On Sat, Sep 1, 2012 at 8:19 PM, Olloth wrote: >> GitHub user Olloth opened a pull request: >> >> https://github.com/apache/commons-lang/pull/2 >> >> Update src/main/java/org/apache/commons/lang3/SystemUtils.java >> >> Updated SystemUtils to account for Windows 8. >> >> Windows 8 RTM is released, soon to be going out to consumers. Many >> people are already using it. >> >> The current version is 6.2.9200.16384 (RTM) and the string returned by >> the java property is "Windows 8" in accordance with 7 and other versions. >> >> You can merge this pull request into a Git repository by running: >> >> $ git pull https://github.com/Olloth/commons-lang patch-1 >> >> Alternatively you can review and apply these changes as the patch at: >> >> https://github.com/apache/commons-lang/pull/2.patch >> >> >> commit f39454442d3baee7ff7473d9251bbf13f1a0113a >> Author: Dalton J Pelc >> Date: 2012-09-01T17:17:24-07:00 >> >> Update src/main/java/org/apache/commons/lang3/SystemUtils.java >> >> Updated SystemUtils to account for Windows 8. >> >> >> >> >> - >> 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] Re: Single root for Exceptions
Hello.
> >
> >> >>>
> >> >>> in ConjugateGradient, I get the following error
> >> >>>
> >> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
> >> >>> throws clause in
> >> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
> >> >>> RealLinearOperator, RealVector, RealVector)"
> >> >>>
> >> >>> This comes from the fact that general iterative solvers do not require
> >> >>> positive definite operators (therefore, no
> >> >>> "throws NonPositiveDefiniteOperatorException" clause in the signature
> >> >>> of
> >> >>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
> >> >>> gradient does.
> >> >>>
> >> >>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
> >> >>> clause in the signature of
> >> >>> PreconditionedIterativeLinearSolver.solveInPlace as well?
> >> >>
> >> >> I think so, as users may use a ConjugateGradient and store it in a
> >> >> variable declared with the base class only. However, I don't know if
> >> >> adding an unchecked exception to the signature of an interface is a
> >> >> compatible change or not.
> >> >>
> >> >> Luc
> >> >>
> >> > clirr does not seem to be complaining, so I'll do as you say. Here is
> >> > what I'm planning to add to the javadoc of the mother abstract class.
> >> > What do you think?
> >> >
> >> > * @throws NonPositiveDefiniteOperatorException if {@code a} or
> >> > {@code m}
> >> > * is not positive definite (required by some iterative solvers)
> >>
> >> Perfect!
> >
> > I don't agree on the principle that base classes/interfaces should be aware
> > of the detailed requirements of their implementations.
> > We can foresee that subclasses might need to throw _some_ kind of exception
> > when something (yet unknown at the time of the interface design) goes wrong.
> > But base classes (or interfaces) should not have to change when a new class
> > extends (or implements) it.
> >
> > For cases like the above, we must create a parent exception (or use an
> > existing one if it is appropriate) in order to convey that subclasses
> > _might_ throw exceptions that inherit from that one.
> > It this particular case, it seems that operators that are not positive
> > definite are illegal for method "solveInPlace", hence we conclude (not
> > surprisingly) that "MathIllegalArgumentException" can be thrown from classes
> > that implement "RealLinearOperator.solveInPlace".
> >
> > In fact, this is even too much of a "guessing" work. And this where a single
> > root can be used to clearly advertize that, by design, CM is supposed to
> > throw only (subclasses of) "MathRunimeException". _That_ exception, and
> > _nothing_ else should really be inserted in the "throws" clause of upper
> > level base classes and interfaces.
> >
> > Referring to the above example, it is the duty of the user of CM to read the
> > documentation of the (concrete) classes he uses if he wants to know which
> > subclass of "MathRuntimeException" may actually be thrown; it is not enough
> > to read the documentation of the interface!
> > To be clear, CM will become a total clutter if upper levels attempt to
> > report everything all the way down. This is in blatant contradiction with
> > the principle (or rule, or best practice) of encapsulation.
> >
> >
> > Best regards,
> > Gilles
> >
> >> > [...]
> >
> > P.S. Practically, at this point, I propose to not touch interfaces or base
> > classes, but only add the "throws" clauses where the methods actually
> > throw the exceptions, and in some cases, one level up (where it is
> > still obvious that a particular condition is required).
> > Of course, that makes it impossible to test the "switch to checked
> > exception" as the work is in progress. For this, let's wait until all
> > the first pass has been completed, then we can see what is missing,
> > and decide while seeing the picture.
> >
> I think some exceptions *must* be shown in some interfaces. For
> example, DimensionMismatchException in FieldMatrix.mul(FieldMatrix).
I didn't deny it. I suggested that _for the time being_, we add the obvious
clauses, i.e. those where the "throw" statement is visible in the body of
the function, or where we know that a method called by this method can
throw[1].
Then we can "propagate" the changes upwards, where it makes sense.
I agree that in your example, the exception should be advertized in the
interface, because this is a precondition of the operation that must hold
for _any_ implementation. [Thus you can add it now if you want ;-)].
Best regards,
Gilles
[1] E.g. like the various "verify..." utility methods.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-lang pull request: Update src/main/java/org/apache/commons/lang3/Sy...
"Cool" as in "that's great that we're getting contributions from folks via Github" or "cool" as in "it's cool to use patches via Github pull requests, since there's an implied license grant"? I agree that it's minor enough that any of us could just implement it "from scratch" and just not worry. Do any of us have a dev environment set up on a windows 8 machine (or VM I guess) yet? On Mon, Sep 3, 2012 at 5:01 AM, Henri Yandell wrote: > Cool to have a patch come in via github. Bear in mind there's nothing > to suggest Olloth is on the mailing list. > > Hen > > On Sat, Sep 1, 2012 at 6:16 PM, James Carman > wrote: >> Can you submit a JIRA and attach a SVN patch please? >> >> On Sat, Sep 1, 2012 at 8:19 PM, Olloth wrote: >>> GitHub user Olloth opened a pull request: >>> >>> https://github.com/apache/commons-lang/pull/2 >>> >>> Update src/main/java/org/apache/commons/lang3/SystemUtils.java >>> >>> Updated SystemUtils to account for Windows 8. >>> >>> Windows 8 RTM is released, soon to be going out to consumers. Many >>> people are already using it. >>> >>> The current version is 6.2.9200.16384 (RTM) and the string returned by >>> the java property is "Windows 8" in accordance with 7 and other versions. >>> >>> You can merge this pull request into a Git repository by running: >>> >>> $ git pull https://github.com/Olloth/commons-lang patch-1 >>> >>> Alternatively you can review and apply these changes as the patch at: >>> >>> https://github.com/apache/commons-lang/pull/2.patch >>> >>> >>> commit f39454442d3baee7ff7473d9251bbf13f1a0113a >>> Author: Dalton J Pelc >>> Date: 2012-09-01T17:17:24-07:00 >>> >>> Update src/main/java/org/apache/commons/lang3/SystemUtils.java >>> >>> Updated SystemUtils to account for Windows 8. >>> >>> >>> >>> >>> - >>> 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
[math] Fixing and then deprecating isSupportXxxInclusive in RealDistribution interface
The conclusion from [1] was never implemented and I was, once again, confused by these properties when developing some density integration tests last night. I would like to deprecate these properties from the RealDistribution interface, but since removal will have to wait until 4.0, I would like to agree on a precise definition and fix the code to match it in the mean time. The definition that I propose is that isSupportXxxInclusive means that when the density function is applied to the upper or lower bound of support returned by getSupportXxxBound, a finite (i.e. not infinite), not NaN value is returned. The code is now consistent with this definition other than for the F distribution, where the lower bound of support is marked included but the density returns NaN there. If others are in agreement, I will make the deprecations, clarify the javadoc, change the value returned by FDistribution to match the contract and add tests. Phil [1] http://markmail.org/message/dxuxh7eybl7xejde - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Checkstyle and '+' should be on the previous line.
On 9/1/12 10:11 AM, Gary Gregory wrote: I have not tried using it, but the eclipse config that Luc posted [1] includes this line, which I suspect configures this behavior: I am curious why you don't like it. To me, it is similar to putting the open paren for a method call on the preceding line. Easier to read for me at least. Of course, in keeping with my normal "too many rules == evil" view, I don't see it as something that needs to be standardized :) Phil [1] http://markmail.org/message/djnlefeodk2xa7bz > Hi All: > > Checkstyle can report warnings like: > > '+' should be on the previous line. > > FWIW, I'm not fond of this particular checkstyle rule. > > Does anyone know if the Eclipse formatter can be made to behave like this? > I've not found such setting in the giant formatter options dialog. I am on > Eclipse 3.7.2. Are there any 4.x users out there? If so, does 4.x deal with > this? > > Thank you, > Gary > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Checkstyle and '+' should be on the previous line.
On Mon, Sep 03, 2012 at 09:59:55AM -0700, Phil Steitz wrote: > On 9/1/12 10:11 AM, Gary Gregory wrote: > > I have not tried using it, but the eclipse config that Luc posted > [1] includes this line, which I suspect configures this behavior: > > id="org.eclipse.jdt.core.formatter.wrap_before_binary_operator" > value="false"/> > > I am curious why you don't like it. To me, it is similar to putting > the open paren for a method call on the preceding line. Easier to > read for me at least. Of course, in keeping with my normal "too > many rules == evil" view, I don't see it as something that needs to > be standardized :) One way to "explain" it: You would not write unary minus on the previous line: double minusOne = - 1; Similarly, before one has become used to this (arbitrary) rule, this is as strange: double xMinusOne = x - 1; [A rationale for writing parenthesis on the same line is that you can figure out more quickly that it is a method call, rather than a reference to a variable.] Gilles > > Phil > > [1] http://markmail.org/message/djnlefeodk2xa7bz > > > Hi All: > > > > Checkstyle can report warnings like: > > > > '+' should be on the previous line. > > > > FWIW, I'm not fond of this particular checkstyle rule. > > > > Does anyone know if the Eclipse formatter can be made to behave like this? > > I've not found such setting in the giant formatter options dialog. I am on > > Eclipse 3.7.2. Are there any 4.x users out there? If so, does 4.x deal with > > this? > > > > Thank you, > > Gary > > > > > - > 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: svn commit: r1380305 - in /commons/proper/codec/trunk/src/main/java/org/apache/commons/codec: Charsets.java binary/Hex.java net/BCodec.java net/QCodec.java net/QuotedPrintableCodec.java
On 3 September 2012 19:37, wrote:
> Author: tn
> Date: Mon Sep 3 18:37:21 2012
> New Revision: 1380305
>
> URL: http://svn.apache.org/viewvc?rev=1380305&view=rev
> Log:
> Fixed findbugs warning wrt unused imports resulting from javadoc types.
Another way to fix this would be to add the exceptions to the throws
clause; then the import would not be redundant (and the Javadoc would
be a bit shorter).
But not necessary to change this here; perhaps consider for other cases?
> Modified:
>
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
>
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
>
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
>
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/QCodec.java
>
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/QuotedPrintableCodec.java
>
> Modified:
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java?rev=1380305&r1=1380304&r2=1380305&view=diff
> ==
> ---
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
> (original)
> +++
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
> Mon Sep 3 18:37:21 2012
> @@ -17,7 +17,6 @@
> package org.apache.commons.codec;
>
> import java.nio.charset.Charset;
> -import java.nio.charset.UnsupportedCharsetException;
>
> /**
> * Charsets required of every implementation of the Java platform.
> @@ -81,7 +80,7 @@ public class Charsets {
> * @param charset
> *The name of the requested charset, may be null.
> * @return a Charset for the named charset
> - * @throws UnsupportedCharsetException
> + * @throws java.nio.charset.UnsupportedCharsetException
> * If the named charset is unavailable
> */
> public static Charset toCharset(String charset) {
>
> Modified:
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java?rev=1380305&r1=1380304&r2=1380305&view=diff
> ==
> ---
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
> (original)
> +++
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
> Mon Sep 3 18:37:21 2012
> @@ -18,7 +18,6 @@
> package org.apache.commons.codec.binary;
>
> import java.nio.charset.Charset;
> -import java.nio.charset.UnsupportedCharsetException;
>
> import org.apache.commons.codec.BinaryDecoder;
> import org.apache.commons.codec.BinaryEncoder;
> @@ -207,7 +206,7 @@ public class Hex implements BinaryEncode
> *
> * @param charsetName
> *the charset name.
> - * @throws UnsupportedCharsetException
> + * @throws java.nio.charset.UnsupportedCharsetException
> * If the named charset is unavailable
> * @since 1.4
> * @since 1.7 throws UnsupportedCharsetException if the named charset is
> unavailable
>
> Modified:
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java?rev=1380305&r1=1380304&r2=1380305&view=diff
> ==
> ---
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
> (original)
> +++
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
> Mon Sep 3 18:37:21 2012
> @@ -19,7 +19,6 @@ package org.apache.commons.codec.net;
>
> import java.io.UnsupportedEncodingException;
> import java.nio.charset.Charset;
> -import java.nio.charset.UnsupportedCharsetException;
>
> import org.apache.commons.codec.Charsets;
> import org.apache.commons.codec.DecoderException;
> @@ -75,7 +74,7 @@ public class BCodec extends RFC1522Codec
> *
> * @param charsetName
> *the default charset to use.
> - * @throws UnsupportedCharsetException
> + * @throws java.nio.charset.UnsupportedCharsetException
> * If the named charset is unavailable
> * @since 1.7 throws UnsupportedCharsetException if the named charset is
> unavailable
> * @see href="http://download.oracle.com/javase/6/docs/api/java/nio/charset/Charset.html";>Standard
> charsets
>
> Modified:
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/QCodec.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main
Re: svn commit: r1380305 - in /commons/proper/codec/trunk/src/main/java/org/apache/commons/codec: Charsets.java binary/Hex.java net/BCodec.java net/QCodec.java net/QuotedPrintableCodec.java
On 09/03/2012 08:48 PM, sebb wrote: > On 3 September 2012 19:37, wrote: >> Author: tn >> Date: Mon Sep 3 18:37:21 2012 >> New Revision: 1380305 >> >> URL: http://svn.apache.org/viewvc?rev=1380305&view=rev >> Log: >> Fixed findbugs warning wrt unused imports resulting from javadoc types. > > Another way to fix this would be to add the exceptions to the throws > clause; then the import would not be redundant (and the Javadoc would > be a bit shorter). > > But not necessary to change this here; perhaps consider for other cases? yes good idea, we do this effort now in commons-math, so I guess we could extend it to other components as well. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1380305 - in /commons/proper/codec/trunk/src/main/java/org/apache/commons/codec: Charsets.java binary/Hex.java net/BCodec.java net/QCodec.java net/QuotedPrintableCodec.java
On 3 September 2012 19:55, Thomas Neidhart wrote: > On 09/03/2012 08:48 PM, sebb wrote: >> On 3 September 2012 19:37, wrote: >>> Author: tn >>> Date: Mon Sep 3 18:37:21 2012 >>> New Revision: 1380305 >>> >>> URL: http://svn.apache.org/viewvc?rev=1380305&view=rev >>> Log: >>> Fixed findbugs warning wrt unused imports resulting from javadoc types. >> >> Another way to fix this would be to add the exceptions to the throws >> clause; then the import would not be redundant (and the Javadoc would >> be a bit shorter). >> >> But not necessary to change this here; perhaps consider for other cases? > > yes good idea, we do this effort now in commons-math, so I guess we > could extend it to other components as well. Yes, worth working towards as time permits. I find it a bit odd to see a different list of entries in throws and @throws. I expect to see @throws tags used to document the condition under which each throws entry can occur. > Thomas > > - > 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: svn commit: r1380305 - in /commons/proper/codec/trunk/src/main/java/org/apache/commons/codec: Charsets.java binary/Hex.java net/BCodec.java net/QCodec.java net/QuotedPrintableCodec.java
This is really a shortcoming in FB IMO :(
Gary
On Sep 3, 2012, at 14:48, sebb wrote:
> On 3 September 2012 19:37, wrote:
>> Author: tn
>> Date: Mon Sep 3 18:37:21 2012
>> New Revision: 1380305
>>
>> URL: http://svn.apache.org/viewvc?rev=1380305&view=rev
>> Log:
>> Fixed findbugs warning wrt unused imports resulting from javadoc types.
>
> Another way to fix this would be to add the exceptions to the throws
> clause; then the import would not be redundant (and the Javadoc would
> be a bit shorter).
>
> But not necessary to change this here; perhaps consider for other cases?
>
>> Modified:
>>
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
>>
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
>>
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
>>
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/QCodec.java
>>
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/QuotedPrintableCodec.java
>>
>> Modified:
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java?rev=1380305&r1=1380304&r2=1380305&view=diff
>> ==
>> ---
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
>> (original)
>> +++
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
>> Mon Sep 3 18:37:21 2012
>> @@ -17,7 +17,6 @@
>> package org.apache.commons.codec;
>>
>> import java.nio.charset.Charset;
>> -import java.nio.charset.UnsupportedCharsetException;
>>
>> /**
>> * Charsets required of every implementation of the Java platform.
>> @@ -81,7 +80,7 @@ public class Charsets {
>> * @param charset
>> *The name of the requested charset, may be null.
>> * @return a Charset for the named charset
>> - * @throws UnsupportedCharsetException
>> + * @throws java.nio.charset.UnsupportedCharsetException
>> * If the named charset is unavailable
>> */
>> public static Charset toCharset(String charset) {
>>
>> Modified:
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java?rev=1380305&r1=1380304&r2=1380305&view=diff
>> ==
>> ---
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
>> (original)
>> +++
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Hex.java
>> Mon Sep 3 18:37:21 2012
>> @@ -18,7 +18,6 @@
>> package org.apache.commons.codec.binary;
>>
>> import java.nio.charset.Charset;
>> -import java.nio.charset.UnsupportedCharsetException;
>>
>> import org.apache.commons.codec.BinaryDecoder;
>> import org.apache.commons.codec.BinaryEncoder;
>> @@ -207,7 +206,7 @@ public class Hex implements BinaryEncode
>> *
>> * @param charsetName
>> *the charset name.
>> - * @throws UnsupportedCharsetException
>> + * @throws java.nio.charset.UnsupportedCharsetException
>> * If the named charset is unavailable
>> * @since 1.4
>> * @since 1.7 throws UnsupportedCharsetException if the named charset is
>> unavailable
>>
>> Modified:
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java?rev=1380305&r1=1380304&r2=1380305&view=diff
>> ==
>> ---
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
>> (original)
>> +++
>> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/BCodec.java
>> Mon Sep 3 18:37:21 2012
>> @@ -19,7 +19,6 @@ package org.apache.commons.codec.net;
>>
>> import java.io.UnsupportedEncodingException;
>> import java.nio.charset.Charset;
>> -import java.nio.charset.UnsupportedCharsetException;
>>
>> import org.apache.commons.codec.Charsets;
>> import org.apache.commons.codec.DecoderException;
>> @@ -75,7 +74,7 @@ public class BCodec extends RFC1522Codec
>> *
>> * @param charsetName
>> *the default charset to use.
>> - * @throws UnsupportedCharsetException
>> + * @throws java.nio.charset.UnsupportedCharsetException
>> * If the named charset is unavailable
>> * @since 1.7 throws UnsupportedCharsetException if the named charset is
>> unavailable
>> * @see > href="http://download.oracle.com/javase/6/docs/api/java/nio/charset/Charset.html";>Standard
>> charse
Re: [all] Checkstyle and '+' should be on the previous line.
On Sep 3, 2012, at 14:13, Gilles Sadowski wrote: > On Mon, Sep 03, 2012 at 09:59:55AM -0700, Phil Steitz wrote: >> On 9/1/12 10:11 AM, Gary Gregory wrote: >> >> I have not tried using it, but the eclipse config that Luc posted >> [1] includes this line, which I suspect configures this behavior: >> >> > id="org.eclipse.jdt.core.formatter.wrap_before_binary_operator" >> value="false"/> >> >> I am curious why you don't like it. To me, it is similar to putting >> the open paren for a method call on the preceding line. Easier to >> read for me at least. Of course, in keeping with my normal "too >> many rules == evil" view, I don't see it as something that needs to >> be standardized :) > > One way to "explain" it: You would not write unary minus on the previous > line: > double minusOne = - >1; That makes sense for unary guys at least. G > > Similarly, before one has become used to this (arbitrary) rule, this is as > strange: > double xMinusOne = x - >1; > > [A rationale for writing parenthesis on the same line is that you can figure > out more quickly that it is a method call, rather than a reference to a > variable.] > > > Gilles > >> >> Phil >> >> [1] http://markmail.org/message/djnlefeodk2xa7bz >> >>> Hi All: >>> >>> Checkstyle can report warnings like: >>> >>> '+' should be on the previous line. >>> >>> FWIW, I'm not fond of this particular checkstyle rule. >>> >>> Does anyone know if the Eclipse formatter can be made to behave like this? >>> I've not found such setting in the giant formatter options dialog. I am on >>> Eclipse 3.7.2. Are there any 4.x users out there? If so, does 4.x deal with >>> this? >>> >>> Thank you, >>> Gary >>> >> >> >> - >> 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] UnexpectedNegativeIntegerException
> > [...] > > > > There must be something imprecise in the CM project description which I've > > read somewhere, mentioning "state-of-the-art". I understood it as "best > > practices in Java programming and OO design", but I must have been wrong. > > Probably what you remember reading is this on the home page: > " All algorithms are fully documented and follow generally accepted > best practices." Yes, that's it. And indeed, the first thing that came to my mind is "best [programming] practices". Those best practices evolve over time and vary with the language (or more exactly, with the paradigm supported by the language). [For an example of both and how incoherent, incomprehensible and unmaintainable a code can be when we mix oil and water, please look at "BOBYQAOptimizer"! And this is already after dozens of hours converting from Fortran (goto etc.) to Java (OO).] > We have never claimed to be anything more than a practially useful, > open source, open-development Java mathematics library implementing > standard algorithms with no dependencies or IP encumberance and good > documentation. This is consistent with how other Commons components > describe themselves. The key is that *usefulness*, *ease of use* > and *approachability of the code* is more important than any one > developer's idea of what constitutes "best coding practices" or > "state-of-the-art" Java (whatever that means). None of the qualities which you cite as worthy goals are in contradiction with what you say is less important. In fact, quite the contrary, applying the paradigm supported by the language improves everything else (ease of use, approachability, hence usefulness). In our case, respecting the basic tenets of object-oriented programming should be a top (!) priority if we hope to to build a library for the longer term. IMHO, we should promote Java (OO) state-of-the-art best practices when designing the API and writing the code. Sometimes, we can arrive to a dead-end, where we'd need to derogate to the rules. At that point we might realize that the design was not good enough to cater for all (new) the requirements. If we have to maintain compatibility, and if there is really no other choice, only then should we be allowed to break the rules. If we can break compatibility, then the design can be evolved, based on the new insights. Failing to do that from time to time will be the cause of the demise of CM (as of many other programming projects). > It seems a reasonable compromise in this case would be to provide > the getters that Luc is asking for (making the library easier to > use), while at the same time continuing to build out the exception > hierarchy so that more use cases can be handled without > programmatically unpacking exception contexts. All I suggest is that we are aware that there is something fundamentally wrong (in the sense of OO fundamentals) with the approach which you aptly describe as "unpacking exception contexts". [I think that this and other decisions will hurt the project later. But I can understand that a pressing need might need to be solved urgently. I did not mean to oppose adding the accessors (I even thought they existed already!); I am arguing about the principles.] We should also acknowledge that this change is useful only for people who will actually _read the source code_ (in order to spot what pattern was passed to the raised exception): the pattern is not documented (and rightly so IMO!). Until we have cleaned up the "LocalizedFormats" (removing all duplicates or near duplicates), we should not be tied to keep any pattern in the API. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Checkstyle and '+' should be on the previous line.
On Sep 3, 2012, at 12:25 PM, Gary Gregory wrote: > On Sep 3, 2012, at 14:13, Gilles Sadowski > wrote: > >> On Mon, Sep 03, 2012 at 09:59:55AM -0700, Phil Steitz wrote: >>> On 9/1/12 10:11 AM, Gary Gregory wrote: >>> >>> I have not tried using it, but the eclipse config that Luc posted >>> [1] includes this line, which I suspect configures this behavior: >>> >>> >> id="org.eclipse.jdt.core.formatter.wrap_before_binary_operator" >>> value="false"/> >>> >>> I am curious why you don't like it. To me, it is similar to putting >>> the open paren for a method call on the preceding line. Easier to >>> read for me at least. Of course, in keeping with my normal "too >>> many rules == evil" view, I don't see it as something that needs to >>> be standardized :) >> >> One way to "explain" it: You would not write unary minus on the previous >> line: >> double minusOne = - >> 1; > > That makes sense for unary guys at least. > Sort of ridiculous example, as the - would never be followed by a space, so would never be wrapped that way. The rule above and I suspect the checkstyle check, refers to binary operators. Phil > G > >> >> Similarly, before one has become used to this (arbitrary) rule, this is as >> strange: >> double xMinusOne = x - >> 1; >> >> [A rationale for writing parenthesis on the same line is that you can figure >> out more quickly that it is a method call, rather than a reference to a >> variable.] >> >> >> Gilles >> >>> >>> Phil >>> >>> [1] http://markmail.org/message/djnlefeodk2xa7bz >>> Hi All: Checkstyle can report warnings like: '+' should be on the previous line. FWIW, I'm not fond of this particular checkstyle rule. Does anyone know if the Eclipse formatter can be made to behave like this? I've not found such setting in the giant formatter options dialog. I am on Eclipse 3.7.2. Are there any 4.x users out there? If so, does 4.x deal with this? Thank you, Gary >>> >>> >>> - >>> 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: [all] Checkstyle and '+' should be on the previous line.
On Mon, Sep 03, 2012 at 02:19:01PM -0700, Phil Steitz wrote: > > > > > On Sep 3, 2012, at 12:25 PM, Gary Gregory wrote: > > > On Sep 3, 2012, at 14:13, Gilles Sadowski > > wrote: > > > >> On Mon, Sep 03, 2012 at 09:59:55AM -0700, Phil Steitz wrote: > >>> On 9/1/12 10:11 AM, Gary Gregory wrote: > >>> > >>> I have not tried using it, but the eclipse config that Luc posted > >>> [1] includes this line, which I suspect configures this behavior: > >>> > >>> >>> id="org.eclipse.jdt.core.formatter.wrap_before_binary_operator" > >>> value="false"/> > >>> > >>> I am curious why you don't like it. To me, it is similar to putting > >>> the open paren for a method call on the preceding line. Easier to > >>> read for me at least. Of course, in keeping with my normal "too > >>> many rules == evil" view, I don't see it as something that needs to > >>> be standardized :) > >> > >> One way to "explain" it: You would not write unary minus on the previous > >> line: > >> double minusOne = - > >> 1; > > > > That makes sense for unary guys at least. > > > Sort of ridiculous example, Perhaps you didn't get it... > as the - would never be followed by a space, And why not? > so would never be wrapped that way. Never? I've just wrapped it that way. It's a valid expression, and not using that notation is purely a result convention/rule/best practice/taste. > The rule above and I suspect the checkstylecheck, refers to binary > operators. What's the point? My point is that - x is not more ridiculous than y - x If you do find it ridiculous, it is indeed only because of habit; others might be used to (and thus prefer) y - x Gilles > > Phil > > > G > > > >> > >> Similarly, before one has become used to this (arbitrary) rule, this is as > >> strange: > >> double xMinusOne = x - > >> 1; > >> > >> [A rationale for writing parenthesis on the same line is that you can > >> figure > >> out more quickly that it is a method call, rather than a reference to a > >> variable.] > >> > >> > >> Gilles > >> > >>> > >>> Phil > >>> > >>> [1] http://markmail.org/message/djnlefeodk2xa7bz > >>> > Hi All: > > Checkstyle can report warnings like: > > '+' should be on the previous line. > > FWIW, I'm not fond of this particular checkstyle rule. > > Does anyone know if the Eclipse formatter can be made to behave like > this? > I've not found such setting in the giant formatter options dialog. I am > on > Eclipse 3.7.2. Are there any 4.x users out there? If so, does 4.x deal > with > this? > > Thank you, > Gary > > >>> > >>> > >>> - > >>> 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
[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) 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-dbcp has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 53 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-04092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-04092012.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
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 53 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-04092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-04092012.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
[math] Deprecate, then remove OpenMapRealVectors?
Hi, now the summer is over, it is time to revive this thread [1]. It is copied to both user@ and dev@ mailing lists. Recently, many problems have been found out with class OpenMapRealVector [2], [3], to the point that we are considering the complete removal of this class in upcoming versions [4]. Before any decision is taken, we need some input from potential users (if any) of this class. Any feedback would be most welcome! Thanks in advance, Sébastien Brisard [1] http://markmail.org/thread/vu2ulvyt7pseyheq [2] https://issues.apache.org/jira/browse/MATH-803 [3] https://issues.apache.org/jira/browse/MATH-821 [4] http://markmail.org/message/nwbnkpbpnrbfpqnd - 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
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 58 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: 1346730877511
[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
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 75 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: Tue Sep 04 05:05:27 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
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 58 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.017 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 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.069 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 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.005 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.312 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.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 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: Tue Sep 04 05:20:58 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
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 53 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: 16 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: 1346736390627
[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]
Re: [math] UnexpectedNegativeIntegerException
Hi, I realize I'm a little late to the party here, so if I'm asking or suggesting things that are naive just let me know straight up, and I'll try to educate myself better. I will say that I really enjoy reading these threads because I learn a great deal from them. As a user of commons math I think it would be great if a each exception mapped to a "One of a kind problem". So instead of having a NegativeIntegerException, which is generic and could be used in a lot of places, have SuperDuperOptimizerNegativeIntegerException, which is only thrown in one place. Is this possible? Cheers, - Ole On 09/03/2012 03:56 PM, Gilles Sadowski wrote: [...] There must be something imprecise in the CM project description which I've read somewhere, mentioning "state-of-the-art". I understood it as "best practices in Java programming and OO design", but I must have been wrong. Probably what you remember reading is this on the home page: " All algorithms are fully documented and follow generally accepted best practices." Yes, that's it. And indeed, the first thing that came to my mind is "best [programming] practices". Those best practices evolve over time and vary with the language (or more exactly, with the paradigm supported by the language). [For an example of both and how incoherent, incomprehensible and unmaintainable a code can be when we mix oil and water, please look at "BOBYQAOptimizer"! And this is already after dozens of hours converting from Fortran (goto etc.) to Java (OO).] We have never claimed to be anything more than a practially useful, open source, open-development Java mathematics library implementing standard algorithms with no dependencies or IP encumberance and good documentation. This is consistent with how other Commons components describe themselves. The key is that *usefulness*, *ease of use* and *approachability of the code* is more important than any one developer's idea of what constitutes "best coding practices" or "state-of-the-art" Java (whatever that means). None of the qualities which you cite as worthy goals are in contradiction with what you say is less important. In fact, quite the contrary, applying the paradigm supported by the language improves everything else (ease of use, approachability, hence usefulness). In our case, respecting the basic tenets of object-oriented programming should be a top (!) priority if we hope to to build a library for the longer term. IMHO, we should promote Java (OO) state-of-the-art best practices when designing the API and writing the code. Sometimes, we can arrive to a dead-end, where we'd need to derogate to the rules. At that point we might realize that the design was not good enough to cater for all (new) the requirements. If we have to maintain compatibility, and if there is really no other choice, only then should we be allowed to break the rules. If we can break compatibility, then the design can be evolved, based on the new insights. Failing to do that from time to time will be the cause of the demise of CM (as of many other programming projects). It seems a reasonable compromise in this case would be to provide the getters that Luc is asking for (making the library easier to use), while at the same time continuing to build out the exception hierarchy so that more use cases can be handled without programmatically unpacking exception contexts. All I suggest is that we are aware that there is something fundamentally wrong (in the sense of OO fundamentals) with the approach which you aptly describe as "unpacking exception contexts". [I think that this and other decisions will hurt the project later. But I can understand that a pressing need might need to be solved urgently. I did not mean to oppose adding the accessors (I even thought they existed already!); I am arguing about the principles.] We should also acknowledge that this change is useful only for people who will actually _read the source code_ (in order to spot what pattern was passed to the raised exception): the pattern is not documented (and rightly so IMO!). Until we have cleaned up the "LocalizedFormats" (removing all duplicates or near duplicates), we should not be tied to keep any pattern in the API. Regards, 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
[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 58 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: 29 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.207 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.079 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]
