Re: [math] Using reflection to test private methods
Hi
2012/12/1 Gilles Sadowski
> On Sat, Dec 01, 2012 at 09:39:04PM +, sebb wrote:
> > On 30 November 2012 11:43, Luc Maisonobe wrote:
> > > Le 30/11/2012 09:19, Thomas Neidhart a écrit :
> > >> On Fri, Nov 30, 2012 at 8:06 AM, Sébastien Brisard <
> > >> sebastien.bris...@m4x.org> wrote:
> > >>
> > >>> Hi,
> > >>> I've already posted the same question in another thread [1], but I
> thought
> > >>> having a dedicated thread would increase its visibility.
> > >>>
> > >>> Here is my problem. The new implementation of Beta.logBeta(double,
> double)
> > >>> I'm currently working on relies on several private methods through a
> rather
> > >>> complex branching.
> > >>> Due to this complicated branching, I find it much safer to have
> direct
> > >>> tests for these private methods, instead of relying on the tests of
> > >>> Beta.logBeta to validate these methods.
> > >>> Therefore, in order to preserve encapsulation (these private methods
> should
> > >>> really remain private, and not package private, as I previously did
> [2]), I
> > >>> propose to use reflection in the unit tests to access these private
> > >>> methods. I've tested this option locally, it seems to me that it is a
> > >>> viable option.
> > >>>
> > >>> What do you think about this compromise?
> > >>>
> > >>
> > >> imho, this is perfectly valid in such a specific case, and I had to
> do the
> > >> same in other projects occasionally.
> > >
> > > +1, and I used the same trick already in some projects.
> >
> > +1 to using reflection in test cases if necessary.
> > [I don't see why that even needs a vote!]
> >
> > However, I don't see what the issue is with package-private methods,
> > so long as the reason for the removal of the private qualifier is
> > documented.
> >
> > If 3rd party application code creates classes in o.a.c.m packages,
> > then any problems that result are entirely up to them to resolve...
>
> IMHO, that's really not the problem (i.e. I agree its theirs).
> I just find it dirty from a desing point-of-view to have visibility scope
> guided by how easy it would to test with Junit.
> Scope in (useful) code should be guided by internal consistency (leaving
> any
> testing consideration).
>
I agree with you (mea culpa). If we ever need these auxiliary methods, we
can increase their scope without breaking compatibility.
> After some time, it becomes a soiurce or questioning ("Why is this code
> package private?"). [And no, I don't think that it is enough reason to
> state that reason (for "Junit" testing) is the documentation.]
>
> Sébastien's case rarely occurs, and his workaround is fine. So is his
> willingness to provide exhaustive coverage!
>
>
> Plus it was fun to use introspection (!). I learned something!
> Best,
> Gilles
>
Thanks anyway for this interesting conversation. I think this is a nice
workaround, but sometimes the gap between "nice workaround" and "dirty
trick" is very narrow indeed. I just wanted to check with all of you guys
that I didn't go too far in the direction of the dirty tricks...
Best regards,
Sébastien
Re: [math] Using reflection to test private methods
Hi,
2012/12/2 Ted Dunning
> Google has a nice @ExposedForTesting annotation that they use for this.
>
> There are numerous instances in guava where otherwise private methods are
> exposed to the test suite for testing. It makes a lot of sense, and there
> are no questions to anybody looking at the code about what is happening.
> If you really want to do so, you can even implement a code walker that
> guarantees that all methods are annotated with the access level and level
> of stability.
>
> Franckly, I don't know where you guys find the time to study all these
libraries...
I'm amazed!
S
> On Sat, Dec 1, 2012 at 2:25 PM, Gilles Sadowski <
> gil...@harfang.homelinux.org> wrote:
>
> > After some time, it becomes a soiurce or questioning ("Why is this code
> > package private?"). [And no, I don't think that it is enough reason to
> > state that reason (for "Junit" testing) is the doc
> >
>
Re: [math] Using reflection to test private methods
On 2 December 2012 09:58, Sébastien Brisard wrote:
> Hi
>
>
> 2012/12/1 Gilles Sadowski
>
>> On Sat, Dec 01, 2012 at 09:39:04PM +, sebb wrote:
>> > On 30 November 2012 11:43, Luc Maisonobe wrote:
>> > > Le 30/11/2012 09:19, Thomas Neidhart a écrit :
>> > >> On Fri, Nov 30, 2012 at 8:06 AM, Sébastien Brisard <
>> > >> sebastien.bris...@m4x.org> wrote:
>> > >>
>> > >>> Hi,
>> > >>> I've already posted the same question in another thread [1], but I
>> thought
>> > >>> having a dedicated thread would increase its visibility.
>> > >>>
>> > >>> Here is my problem. The new implementation of Beta.logBeta(double,
>> double)
>> > >>> I'm currently working on relies on several private methods through a
>> rather
>> > >>> complex branching.
>> > >>> Due to this complicated branching, I find it much safer to have
>> direct
>> > >>> tests for these private methods, instead of relying on the tests of
>> > >>> Beta.logBeta to validate these methods.
>> > >>> Therefore, in order to preserve encapsulation (these private methods
>> should
>> > >>> really remain private, and not package private, as I previously did
>> [2]), I
>> > >>> propose to use reflection in the unit tests to access these private
>> > >>> methods. I've tested this option locally, it seems to me that it is a
>> > >>> viable option.
>> > >>>
>> > >>> What do you think about this compromise?
>> > >>>
>> > >>
>> > >> imho, this is perfectly valid in such a specific case, and I had to
>> do the
>> > >> same in other projects occasionally.
>> > >
>> > > +1, and I used the same trick already in some projects.
>> >
>> > +1 to using reflection in test cases if necessary.
>> > [I don't see why that even needs a vote!]
>> >
>> > However, I don't see what the issue is with package-private methods,
>> > so long as the reason for the removal of the private qualifier is
>> > documented.
>> >
>> > If 3rd party application code creates classes in o.a.c.m packages,
>> > then any problems that result are entirely up to them to resolve...
>>
>> IMHO, that's really not the problem (i.e. I agree its theirs).
>> I just find it dirty from a desing point-of-view to have visibility scope
>> guided by how easy it would to test with Junit.
>> Scope in (useful) code should be guided by internal consistency (leaving
>> any
>> testing consideration).
>>
> I agree with you (mea culpa). If we ever need these auxiliary methods, we
> can increase their scope without breaking compatibility.
>
>
>> After some time, it becomes a soiurce or questioning ("Why is this code
>> package private?"). [And no, I don't think that it is enough reason to
>> state that reason (for "Junit" testing) is the documentation.]
>>
>> Sébastien's case rarely occurs, and his workaround is fine. So is his
>> willingness to provide exhaustive coverage!
>>
>>
>> Plus it was fun to use introspection (!). I learned something!
>
>
>> Best,
>> Gilles
>>
>
> Thanks anyway for this interesting conversation. I think this is a nice
> workaround, but sometimes the gap between "nice workaround" and "dirty
> trick" is very narrow indeed. I just wanted to check with all of you guys
> that I didn't go too far in the direction of the dirty tricks...
IMO test classes can use tricks that would not be suitable for the
main code classes; reflection seems perfectly OK for test classes.
However, of course tests may then break if private methods/fields etc
are renamed, so it might be as well to add a comment to the code to
say that the method is accessed from test code.
> Best regards,
> Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Using reflection to test private methods
Hi,
2012/12/2 sebb
> On 2 December 2012 09:58, Sébastien Brisard
> wrote:
> > Hi
> >
> >
> > 2012/12/1 Gilles Sadowski
> >
> >> On Sat, Dec 01, 2012 at 09:39:04PM +, sebb wrote:
> >> > On 30 November 2012 11:43, Luc Maisonobe
> wrote:
> >> > > Le 30/11/2012 09:19, Thomas Neidhart a écrit :
> >> > >> On Fri, Nov 30, 2012 at 8:06 AM, Sébastien Brisard <
> >> > >> sebastien.bris...@m4x.org> wrote:
> >> > >>
> >> > >>> Hi,
> >> > >>> I've already posted the same question in another thread [1], but I
> >> thought
> >> > >>> having a dedicated thread would increase its visibility.
> >> > >>>
> >> > >>> Here is my problem. The new implementation of Beta.logBeta(double,
> >> double)
> >> > >>> I'm currently working on relies on several private methods
> through a
> >> rather
> >> > >>> complex branching.
> >> > >>> Due to this complicated branching, I find it much safer to have
> >> direct
> >> > >>> tests for these private methods, instead of relying on the tests
> of
> >> > >>> Beta.logBeta to validate these methods.
> >> > >>> Therefore, in order to preserve encapsulation (these private
> methods
> >> should
> >> > >>> really remain private, and not package private, as I previously
> did
> >> [2]), I
> >> > >>> propose to use reflection in the unit tests to access these
> private
> >> > >>> methods. I've tested this option locally, it seems to me that it
> is a
> >> > >>> viable option.
> >> > >>>
> >> > >>> What do you think about this compromise?
> >> > >>>
> >> > >>
> >> > >> imho, this is perfectly valid in such a specific case, and I had to
> >> do the
> >> > >> same in other projects occasionally.
> >> > >
> >> > > +1, and I used the same trick already in some projects.
> >> >
> >> > +1 to using reflection in test cases if necessary.
> >> > [I don't see why that even needs a vote!]
> >> >
> >> > However, I don't see what the issue is with package-private methods,
> >> > so long as the reason for the removal of the private qualifier is
> >> > documented.
> >> >
> >> > If 3rd party application code creates classes in o.a.c.m packages,
> >> > then any problems that result are entirely up to them to resolve...
> >>
> >> IMHO, that's really not the problem (i.e. I agree its theirs).
> >> I just find it dirty from a desing point-of-view to have visibility
> scope
> >> guided by how easy it would to test with Junit.
> >> Scope in (useful) code should be guided by internal consistency (leaving
> >> any
> >> testing consideration).
> >>
> > I agree with you (mea culpa). If we ever need these auxiliary methods, we
> > can increase their scope without breaking compatibility.
> >
> >
> >> After some time, it becomes a soiurce or questioning ("Why is this code
> >> package private?"). [And no, I don't think that it is enough reason to
> >> state that reason (for "Junit" testing) is the documentation.]
> >>
> >> Sébastien's case rarely occurs, and his workaround is fine. So is his
> >> willingness to provide exhaustive coverage!
> >>
> >>
> >> Plus it was fun to use introspection (!). I learned something!
> >
> >
> >> Best,
> >> Gilles
> >>
> >
> > Thanks anyway for this interesting conversation. I think this is a nice
> > workaround, but sometimes the gap between "nice workaround" and "dirty
> > trick" is very narrow indeed. I just wanted to check with all of you guys
> > that I didn't go too far in the direction of the dirty tricks...
>
> IMO test classes can use tricks that would not be suitable for the
> main code classes; reflection seems perfectly OK for test classes.
>
> However, of course tests may then break if private methods/fields etc
> are renamed, so it might be as well to add a comment to the code to
> say that the method is accessed from test code.
>
> That's an excellent suggestion. Will do that! Thanks a lot,
Sébastien
>
> > Best regards,
> > Sébastien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")
Hello.
> >
> > I would propose to simply revert my changes on the optimization package
> > and prepare for a reorganization for 4.0. I understand I focused only on
> > the type of problems Gilles and myself routinely use, i .e. small size
> > problems
> > where the cost of the evaluation is several orders of magnitude larger than
> > the
> > data copying. I forgot the dual case with very large data sets. I
> > apologize for that.
>
> In the context of an FLOSS project, I don't think that you should apologize
> for that. We all do our best (and sometimes beyond) and the lack of full
> problem coverage should certainly not rest on the usual suspects (eh,
> contributors, I mean. ;-)
>
> >
> > When 3.1 will be out, we will have to solve this so both cases are handled
> > efficiently,
> > and this would probably be implemented in 4.0.
> >
> > Does this seems reasonable?
>
> At this point, no!
>
> I really want to understand what is wrong, and improve the API on all
> accounts (the issues you had, the one I raised, and the feedback from
> Konstantin, plus advice from others if possible).
If I understood correctly, the main API problem is that the objective
function and gradient or Jacobian are accessed separately. This forces users
who have code to compute the value and Jacobian together to create an adapter
that can return the two functions (objective and Jacobian) required by the
API but would avoid the computation if the a call to the other was already
made with the same parameter values.
For example, instead of passing a "DifferentiableMultivariateVectorFunction"
to the method "optimize" in "AbstractLeastSquareOptimizer", a type like the
following would be required:
-
interface VectorFunctionWithJacobian {
ValueAndGradient[] computeValueAndJacobian(double[] parameters);
}
-
with
-
public class ValueAndGradient {
/** Value of a function at a given point. */
private final double value;
/** Gradient of the function at the same point. */
private final double[] gradient;
/**
* Creates an instance for the given value and gradient.
* Note that no copy is performed: this instance will contain references
* to the original data.
*
* @param value Value.
* @param gradient Vector.
*/
public ValueAndGradient(double value,
double[] gradient) {
this.value = value;
this.gradient = gradient;
}
/**
* @eturn a reference to the value.
*/
public double getValue() {
}
/**
* @eturn a reference to the gradient.
*/
public double[] getGradient() {
return gradient;
}
}
-
Is that a better approach?
IIUC, the "DerivativeStructure" can also be used if just as a storage layout
equivalent to "ValueAndGradient". If so, then the new proposed API
(where the objective function is a "MultivariateDifferentiableVectorFunction")
is indeed better than the old, except for the (perhaps major) caveat that
from the "optimization" package, it indeed looks over-engineered and quite
unfamiliar.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1416248 - in /commons/proper/email/trunk/src: changes/changes.xml java/org/apache/commons/mail/Email.java test/org/apache/commons/mail/EmailTest.java
This should be a place to use var args...
Gary
On Dec 2, 2012, at 15:23, "t...@apache.org" wrote:
> Author: tn
> Date: Sun Dec 2 20:22:27 2012
> New Revision: 1416248
>
> URL: http://svn.apache.org/viewvc?rev=1416248&view=rev
> Log:
> [EMAIL-114] Added new methods to Email to set an array of addresses for to,
> cc, bcc.
>
> Modified:
>commons/proper/email/trunk/src/changes/changes.xml
>commons/proper/email/trunk/src/java/org/apache/commons/mail/Email.java
>commons/proper/email/trunk/src/test/org/apache/commons/mail/EmailTest.java
>
> Modified: commons/proper/email/trunk/src/changes/changes.xml
> URL:
> http://svn.apache.org/viewvc/commons/proper/email/trunk/src/changes/changes.xml?rev=1416248&r1=1416247&r2=1416248&view=diff
> ==
> --- commons/proper/email/trunk/src/changes/changes.xml (original)
> +++ commons/proper/email/trunk/src/changes/changes.xml Sun Dec 2 20:22:27
> 2012
> @@ -23,6 +23,9 @@
>
>
>
> + due-to="Gokul Nanthakumar C">
> +Added new methods addTo(String[]), addCc(String[]) and
> addBcc(String[]) to Email.
> +
>due-to="sebb">
> Removed emulation support for nested exceptions in EmailException.
>
>
> Modified:
> commons/proper/email/trunk/src/java/org/apache/commons/mail/Email.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/email/trunk/src/java/org/apache/commons/mail/Email.java?rev=1416248&r1=1416247&r2=1416248&view=diff
> ==
> --- commons/proper/email/trunk/src/java/org/apache/commons/mail/Email.java
> (original)
> +++ commons/proper/email/trunk/src/java/org/apache/commons/mail/Email.java
> Sun Dec 2 20:22:27 2012
> @@ -646,6 +646,35 @@ public abstract class Email implements E
> }
>
> /**
> + * Add a list of TO recipients to the email. The email
> + * addresses will also be used as the personal names.
> + * The names will be encoded by the charset of
> + * {@link #setCharset(java.lang.String) setCharset()}.
> + * If it is not set, it will be encoded using
> + * the Java platform's default charset (UTF-16) if it contains
> + * non-ASCII characters; otherwise, it is used as is.
> + *
> + * @param emails A String array.
> + * @throws EmailException Indicates an invalid email address.
> + * @return An Email.
> + */
> +public Email addTo(String[] emails)
> +throws EmailException
> +{
> +if(emails == null || emails.length == 0)
> +{
> +throw new EmailException("Address List provided was invalid");
> +}
> +
> +for(int i = 0; i < emails.length; i++)
> +{
> +addTo(emails[i], null);
> +}
> +
> +return this;
> +}
> +
> +/**
> * Add a recipient TO to the email using the specified address and the
> * specified personal name.
> * The name will be encoded by the charset of
> @@ -726,6 +755,35 @@ public abstract class Email implements E
> }
>
> /**
> + * Add an array of CC recipients to the email. The email
> + * addresses will also be used as the personal name.
> + * The names will be encoded by the charset of
> + * {@link #setCharset(java.lang.String) setCharset()}.
> + * If it is not set, it will be encoded using
> + * the Java platform's default charset (UTF-16) if it contains
> + * non-ASCII characters; otherwise, it is used as is.
> + *
> + * @param emails A String array.
> + * @return An Email.
> + * @throws EmailException Indicates an invalid email address.
> + */
> +public Email addCc(String[] emails)
> +throws EmailException
> +{
> +if(emails == null || emails.length == 0)
> +{
> +throw new EmailException("Address List provided was invalid");
> +}
> +
> +for(int i = 0; i < emails.length; i++)
> +{
> +addCc(emails[i], null);
> +}
> +
> +return this;
> +}
> +
> +/**
> * Add a recipient CC to the email using the specified address and the
> * specified personal name.
> * The name will be encoded by the charset of {@link
> #setCharset(java.lang.String) setCharset()}.
> @@ -805,6 +863,35 @@ public abstract class Email implements E
> }
>
> /**
> + * Add an array of blind BCC recipients to the email. The email
> + * addresses will also be used as the personal name.
> + * The names will be encoded by the charset of
> + * {@link #setCharset(java.lang.String) setCharset()}.
> + * If it is not set, it will be encoded using
> + * the Java platform's default charset (UTF-16) if it contains
> + * non-ASCII characters; otherwise, it is used as is.
> + *
> + * @param emails A String array.
> + * @return An Email.
> + * @throws EmailException Indicates an invalid email address
> +
Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")
Gilles Sadowski a écrit :
>Hello.
>
>> >
>> > I would propose to simply revert my changes on the optimization
>package
>> > and prepare for a reorganization for 4.0. I understand I focused
>only on
>> > the type of problems Gilles and myself routinely use, i .e. small
>size problems
>> > where the cost of the evaluation is several orders of magnitude
>larger than the
>> > data copying. I forgot the dual case with very large data sets. I
>apologize for that.
>>
>> In the context of an FLOSS project, I don't think that you should
>apologize
>> for that. We all do our best (and sometimes beyond) and the lack of
>full
>> problem coverage should certainly not rest on the usual suspects (eh,
>> contributors, I mean. ;-)
>>
>> >
>> > When 3.1 will be out, we will have to solve this so both cases are
>handled efficiently,
>> > and this would probably be implemented in 4.0.
>> >
>> > Does this seems reasonable?
>>
>> At this point, no!
>>
>> I really want to understand what is wrong, and improve the API on all
>> accounts (the issues you had, the one I raised, and the feedback from
>> Konstantin, plus advice from others if possible).
>
>If I understood correctly, the main API problem is that the objective
>function and gradient or Jacobian are accessed separately. This forces
>users
>who have code to compute the value and Jacobian together to create an
>adapter
>that can return the two functions (objective and Jacobian) required by
>the
>API but would avoid the computation if the a call to the other was
>already
>made with the same parameter values.
>
>For example, instead of passing a
>"DifferentiableMultivariateVectorFunction"
>to the method "optimize" in "AbstractLeastSquareOptimizer", a type like
>the
>following would be required:
>-
>interface VectorFunctionWithJacobian {
> ValueAndGradient[] computeValueAndJacobian(double[] parameters);
>}
>-
>with
>-
>public class ValueAndGradient {
>/** Value of a function at a given point. */
>private final double value;
>/** Gradient of the function at the same point. */
>private final double[] gradient;
>
>/**
> * Creates an instance for the given value and gradient.
>* Note that no copy is performed: this instance will contain references
> * to the original data.
> *
> * @param value Value.
> * @param gradient Vector.
> */
>public ValueAndGradient(double value,
>double[] gradient) {
>this.value = value;
>this.gradient = gradient;
>}
>
>/**
> * @eturn a reference to the value.
> */
>public double getValue() {
>}
>/**
> * @eturn a reference to the gradient.
> */
>public double[] getGradient() {
>return gradient;
>}
>}
>-
>
>Is that a better approach?
>
>IIUC, the "DerivativeStructure" can also be used if just as a storage
>layout
>equivalent to "ValueAndGradient". If so, then the new proposed API
>(where the objective function is a
>"MultivariateDifferentiableVectorFunction")
>is indeed better than the old, except for the (perhaps major) caveat
>that
>from the "optimization" package, it indeed looks over-engineered and
>quite
>unfamiliar.
Most importantly, it forces data copies, which is a problem for large data sets.
Best regards
Luc
>
>
>Regards,
>Gilles
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1416241 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/SimpleBounds.java
On 2 December 2012 19:34, wrote: > Author: tn > Date: Sun Dec 2 19:34:05 2012 > New Revision: 1416241 > > URL: http://svn.apache.org/viewvc?rev=1416241&view=rev > Log: > Added missing keywords. > > Modified: > > commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/SimpleBounds.java >(props changed) > > Propchange: > commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/SimpleBounds.java > -- > svn:keywords = Author Date Id Revision $Date$ should not be used as it is locale-specific; this causes problems when checking releases against SVN tags. $Author$ is not useful - the author of the last change does not really mean anything much. However, so long as those keywords aren't actually used the propchange does not matter. > - 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 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-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-03122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-03122012.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 220 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-03122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-03122012.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 clas
[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 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-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 13 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: 1354506656686
[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.
[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 242 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: 1 min 16 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: 1 minute 14 seconds [INFO] Finished at: Mon Dec 03 05:12:49 UTC 2012 [INFO] Final Memory: 114M/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/comm
[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 56 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 - Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Results : Tests in error: testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter) testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter) testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter) testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter) testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testCreateNullObject(org.apache.commons.proxy.TestProxyUtils) testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils) Tests run: 179, Failures: 0, Errors: 28, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There
[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 220 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: 17 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
-
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
[WARNING] The parameter expression: 'project.build.resources' used in mojo:
'process' has been deprecated. Use 'project.resources' instead.
[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: 1354512835525
[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 29 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 Mav
[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 225 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: 24 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.311 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.064 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
Re: svn commit: r1416248 - in /commons/proper/email/trunk/src: changes/changes.xml java/org/apache/commons/mail/Email.java test/org/apache/commons/mail/EmailTest.java
On 12/02/2012 11:07 PM, Gary Gregory wrote: > This should be a place to use var args... Thanks for the hint, in this case I could not use it as email still has to be (source) compatible with jdk 1.4. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1416241 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/SimpleBounds.java
On 12/03/2012 01:43 AM, sebb wrote: > On 2 December 2012 19:34, wrote: >> Author: tn >> Date: Sun Dec 2 19:34:05 2012 >> New Revision: 1416241 >> >> URL: http://svn.apache.org/viewvc?rev=1416241&view=rev >> Log: >> Added missing keywords. >> >> Modified: >> >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/SimpleBounds.java >>(props changed) >> >> Propchange: >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/SimpleBounds.java >> -- >> svn:keywords = Author Date Id Revision > > $Date$ should not be used as it is locale-specific; this causes > problems when checking releases against SVN tags. > > $Author$ is not useful - the author of the last change does not > really mean anything much. > > However, so long as those keywords aren't actually used the propchange > does not matter. Yes, you are right, we do not use this keywords, but the propset should reflect this too. In fact I just re-used the keywords from another file, but I can change all source files to only set 'Id Revision'. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
