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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 291 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.253 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 misplaced 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 foo 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 bar 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 datamodel 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 data 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 baz 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.102 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] 

Re: [weaver] SPI decisions

2013-01-05 Thread Mark Struberg




- Original Message -
 From: Matt Benson gudnabr...@gmail.com

 Weaver#weave():
 
   Currently there are separate methods for weaving a class vs. a method.  I
 think it would be sufficient and cleaner to have a class weaving method
 only; having provided its interests, the Weaver can presumably 
 figure out
 what to do with a class that has been determined to match. 

Yes that might be an option. I added it because sometimes you are interested in 
just a few methods as opposed to having to scan this all yourself (which is 
redundant because xbean-finder does it much more efficiently).


  Next, it feels
 a little odd to use a loaded Class instance to represent a class intended
 for modification.  Should we just use classname here?

Not sure, I need to look at the xbean-finder code. You need to parse the 
bytecode of the class for many things anyway and I don't think it will cause a 
file system lock. 


 
 Weaver#getInterest():
 
   Rather than providing ListClass? extends Annotation, I wonder 
 whether
 it would be more future-proof for this method (pluralized?) to return
 MapClass? extends Annotation, ElementType to say not only which
 Annotation types it is interested in, but where they are expected to be
 found.  This could work comfortably with the type of search registration
 APIs we've discussed for [classscan] in the future.

Yes we could go for it. There was just no need for it yet.


 Weaver#configure():
   This method supplies a target directory where classes are to be found.
 Perhaps too optimistically, I envision a future that could include a
 [weaver] ClassLoader to apply our advice at run, rather than build, time.
 Does anyone have any relevant experience that would guide us in providing
 the most flexible API to permit weaving of classfiles whether on the
 filesystem or otherwise?  Is it going too far to pull in [vfs] v2-core as a
 dependency?

I fear that might be a good bit of additional work to pull off. I'd rather go 
for a version with is working for now. We can still improve it later.

LieGrue,
strub


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



Re: [weaver] SPI decisions

2013-01-05 Thread Matt Benson
On Sat, Jan 5, 2013 at 8:01 AM, Mark Struberg strub...@yahoo.de wrote:





 - Original Message -
  From: Matt Benson gudnabr...@gmail.com
 
  Weaver#weave():
 
Currently there are separate methods for weaving a class vs. a
 method.  I
  think it would be sufficient and cleaner to have a class weaving method
  only; having provided its interests, the Weaver can presumably
  figure out
  what to do with a class that has been determined to match.

 Yes that might be an option. I added it because sometimes you are
 interested in just a few methods as opposed to having to scan this all
 yourself (which is redundant because xbean-finder does it much more
 efficiently).


Point taken; maybe we could combine with point 3 and still end up with a
single method which might be as simple as:

boolean weave(Class?(|String) type, Annotation processingAnnotation,
Map? extends Member, ? extends Annotation annotatedMembers);

...in the end, we're weaving the containing class even when we're *more
specifically* weaving a particular member.  The above reflects another
thought I just had--why pass the annotation type when we can pass the
actual annotation found as the 'processingAnnotation' parameter.  Again,
presumably a given Weaver knows what it's looking for.  WRT
'annotatedMembers', we might be better off to create a custom type and pass
a list of these in case we think we might want to pass the same member with
multiple annotations:

public class AnnotatedMemberA extends Annotation, M extends Member {
  public final A annotation;
  public final M member;

...
}

boolean weave(Class?(|String) type, Annotation processingAnnotation,
ListAnnotatedMember?, ? annotatedMembers);



   Next, it feels
  a little odd to use a loaded Class instance to represent a class intended
  for modification.  Should we just use classname here?

 Not sure, I need to look at the xbean-finder code. You need to parse the
 bytecode of the class for many things anyway and I don't think it will
 cause a file system lock.


 
  Weaver#getInterest():
 
Rather than providing ListClass? extends Annotation, I wonder
  whether
  it would be more future-proof for this method (pluralized?) to return
  MapClass? extends Annotation, ElementType to say not only which
  Annotation types it is interested in, but where they are expected to be
  found.  This could work comfortably with the type of search registration
  APIs we've discussed for [classscan] in the future.

 Yes we could go for it. There was just no need for it yet.


  Weaver#configure():
This method supplies a target directory where classes are to be found.
  Perhaps too optimistically, I envision a future that could include a
  [weaver] ClassLoader to apply our advice at run, rather than build, time.
  Does anyone have any relevant experience that would guide us in providing
  the most flexible API to permit weaving of classfiles whether on the
  filesystem or otherwise?  Is it going too far to pull in [vfs] v2-core
 as a
  dependency?

 I fear that might be a good bit of additional work to pull off. I'd rather
 go for a version with is working for now. We can still improve it later.


I guess there's no sin in an early 2.0 ;)

Thanks!
Matt


 LieGrue,
 strub


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




Re: [configuration] Design discussion

2013-01-05 Thread Oliver Heger

Hi Jörg,

Am 04.01.2013 17:47, schrieb Jörg Schaible:

Hi Oliver,

Oliver Heger wrote:


Hi,

recently I have worked on code regarding the creation of Configuration
objects and reloading support. I have created two Jira tickets [1, 2]
with a description of the problems I see in the current design.

The code in SVN (mainly in the new builder package) should be sufficient
to get a good impression about the direction I would like to go. It is
far more than a pure proof of concept.

However, following this road means some significant changes in the
design and in the way client code uses our classes. Therefore, I would
really appreciate feedback from other committers also interested in this
component.

My main question is: Can we replace the reloading mechanisms available
in 1.x by an approach based on builders as currently implemented in
trunk (e.g. classes
o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
go forward and significantly simplify most of the file-based
configuration implementations.

Thanks
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520


simply go-on with these changes. IMHO it looks good and since separation of
concern leads here to significant code simplification, it's for the best of
us devs and also for our users in the long term. Especially since the new
approach brings also improved functionality.


Thanks for your feedback. Will do!

Oliver



Cheers,
Jörg


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




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



Re: [DBUTILS] Updates for v2.0

2013-01-05 Thread sebb
On 14 December 2012 01:12, William Speirs wspe...@apache.org wrote:
 Adding named params won't break things (actually I was thinking of adding
 this to a 1.x release as well), but removing deprecated code will. Also, I
 was thinking of switching to only supporting named params in the 2.x branch.

Why drop support for positional parameters?

 I guess the real question is, do folks think that forcing the use of named
 params and switching to a groupid to org.apache is enough benefit for the
 cost?

Users will have to switch to named parameters AND change package names
at the same time.
Seems unnecessary to do this in one big bang.

Why not introduce named parameters, and deprecate positional parameters?

 My vote, yes... keep a 1.x branch around for those who cannot or won't
 change, and 2.x for those who can.

Are there enough developers to support both 1.x and 2.x?

 Bill-
 On Dec 13, 2012 8:04 PM, Gary Gregory garydgreg...@gmail.com wrote:

 We only need to change the coordinates if the package name changes to
 account for BC breakage.

 Gary

 On Dec 13, 2012, at 17:47, William Speirs wspe...@apache.org wrote:

  I just submitted
  DBUTILS-105https://issues.apache.org/jira/browse/DBUTILS-105 to
  add support for named params to DB Utils. I'm thinking that if we wrapped
  that up with DBUTILS-95 
 https://issues.apache.org/jira/browse/DBUTILS-95
  and DBUTILS-92 https://issues.apache.org/jira/browse/DBUTILS-92 it
 would
  be worth cutting a new major version.
 
  Also, we should switch the maven convention which probably means changing
  to commons-dbutils2 much like was done with lang.
 
  Thoughts?
 
  Bill-

 -
 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: r1422840 - /commons/proper/lang/trunk/pom.xml

2013-01-05 Thread sebb
Agreed.

Or add the missing updates to the LANG POM with a comment that they
can be dropped once CP 28 is released.

In any case, never depend on a SNAPSHOT.

On 17 December 2012 12:50, Gary Gregory garydgreg...@gmail.com wrote:
 We should release commons parent instead of depending on a snapshot.

 Gary

 On Dec 17, 2012, at 5:42, ol...@apache.org ol...@apache.org wrote:

 Author: olamy
 Date: Mon Dec 17 10:41:50 2012
 New Revision: 1422840

 URL: http://svn.apache.org/viewvc?rev=1422840view=rev
 Log:
 configure site deploy tru svnpubsub

 Modified:
commons/proper/lang/trunk/pom.xml

 Modified: commons/proper/lang/trunk/pom.xml
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/pom.xml?rev=1422840r1=1422839r2=1422840view=diff
 ==
 --- commons/proper/lang/trunk/pom.xml (original)
 +++ commons/proper/lang/trunk/pom.xml Mon Dec 17 10:41:50 2012
 @@ -12,7 +12,7 @@
   parent
 groupIdorg.apache.commons/groupId
 artifactIdcommons-parent/artifactId
 -version27/version
 +version28-SNAPSHOT/version
   /parent
   modelVersion4.0.0/modelVersion
   groupIdorg.apache.commons/groupId
 @@ -483,6 +483,8 @@
 
 commons.release.2.namecommons-lang-${commons.release.2.version}/commons.release.2.name
 commons.jira.idLANG/commons.jira.id
 commons.jira.pid12310481/commons.jira.pid
 +
 +commons.site.pathlang/commons.site.path
   /properties





 -
 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] Missing links on download page

2013-01-05 Thread sebb
On 26 December 2012 18:32, Phil Steitz phil.ste...@gmail.com wrote:
 On 12/24/12 1:13 PM, Gilles Sadowski wrote:
 On Mon, Dec 24, 2012 at 09:27:57AM -0800, Phil Steitz wrote:
 On 12/24/12 4:37 AM, Gilles Sadowski wrote:
 Hi.

 [...]

 Commons Math can be downloaded from the following page:
   http://commons.apache.org/math/download_math.cgi
 I missed that the mvn commons:download-page had generated a new
 template page:
   src/site/xdoc/download_math3.xml
 instead of modifying
   src/site/xdoc/download_math.xml

 Questions:
 1. Is the creation of a new template page expected?
 2. In the affirmative, is it automatically taken into account by the site
generation? I.e. which of the old and new template will eventually be
used to generate the HTML page?
 3. Should the old template be deleted from SVN?
 4. Given that I did not notice the creation of the new template, it was not
included in the tag, and the download page on the site misses the links
to the new release files. How to fix that?
 I think I understand what is going on and how to fix it, but am
 not 100% sure.

 I think the root cause of the problem is r1392022 of the [math] pom,
 where we changed the commons.component.id property to get correct
 osgi bundles created.  This causes the download plugin to generate
 the second template above.  The site plugin does create an html
 page, so there are two.  What I don't get is why only one of them
 ends up on p.a.o (the old one).  In any case, the new one has
 the wrong name, so this needs to be fixed.

 I don't know enough about the download plugin to figure out how to
 really fix this.  Here is a temporary hack that should fix things.

 0) Change commons.component.id back to math locally in the pom.
 1) Change commons.release.version back to 3.1
 2) run commons:download
 3) check in the modified template.
 4) generate the site locally
 5) scp just the download page (download_math.html) to
 p.a.o/www/commons.apache.org/math

 It would probably also work to undo the pom changes after step 3)
 and then do a full site build and deploy.
 Thanks but, hack for hack, I took the more direct route to directly modify
 the HTML page (which is equivalent to your step 5, IIUC). I hope there
 aren't any ill side effects...

 That was actually my first thought ;)

 The rest should be really fixed, i.e. keeping the correct component id and
 having the plugin generate/modify the correct file.

 Perhaps, we should open a JIRA report in order not to forget.

 Agreed, but I am not sure if it should be against [math],
 commons-parent or the download plugin.

 It looks like the download plugin and the osgi plugin both use the
 property commons.component.id.  The value of this property ends up

I think that is actually

commons.componentid

 embedded in the template name - download_xxx.html - that the
 download plugin generates.  This name *must* match download_xxx.cgi
 and the link in site.xml for the download pages to work.  I guess
 one way we can fix this is to rename download_math.cgi (and fix the
 links that point to it elsewhere); but that seems wrong to me.

Agreed.

 Maybe the best approach is to define commons.project.id and have the
 download plugin use that property instead.  What do others think?

Or the plugin could use the new property, if defined, else revert to
commons.componentid.

Otherwise we'd need to default the new property value in commons-parent.

But the name would still need to agree with any links to the download page.
Not sure what generates those.

 One other question I have is where exactly does download_math.cgi
 come from?  I don't see it generated locally or in svn anywhere.

It is the same (small) file for all components.
In the past AFAIK it was just copied from another component and
renamed (on people.a.o).

==

I have seen another approach which does not use separate cgi/html files.
If only I could remember which project used it ...!

It would obviously be simpler to have just the one generated file.

 Phil


 Regards (and Merry Christmas!),
 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


-
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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp has an issue affecting its community integration.
This issue affects 18 projects,
 and has been outstanding for 119 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-06012013.jar:/srv/gump/public/workspace/junit/dist/junit-dep-06012013.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 
TgetObject(String,ClassT)
[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 TgetObject(String,ClassT) in ResultSet
[javac] public class DelegatingResultSet extends 

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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 288 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-06012013.jar:/srv/gump/public/workspace/junit/dist/junit-dep-06012013.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 TgetObject(String,ClassT) in CallableStatement
[javac] public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
TgetObject(String,ClassT)
[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 

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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 119 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 5 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] Building jar: 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook/target/commons-digester3-samples-xmlrules-addressbook-3.3-SNAPSHOT.jar
[INFO] 
[INFO] Building Apache Commons Digester :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-digester3-ap:3.3-SNAPSHOT: checking 
for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-digester3-ap/3.3-SNAPSHOT/commons-digester3-ap-3.3-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-digester3-ap:pom:3.3-SNAPSHOT' in repository 
apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-digester3-ap/3.3-SNAPSHOT/commons-digester3-ap-3.3-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-digester3-ap:jar:3.3-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-digester3-ap:jar:3.3-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-digester3-ap -Dversion=3.3-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-digester3-ap -Dversion=3.3-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-digester3-dist:pom:3.3-SNAPSHOT
2) org.apache.commons:commons-digester3-ap:jar:3.3-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-digester3-dist:pom:3.3-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 4 seconds
[INFO] Finished at: Sun Jan 06 04:48:11 UTC 2013
[INFO] Final Memory: 94M/225M
[INFO] 
-

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

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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-chain2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 310 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: 50 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: 48 seconds
[INFO] Finished at: Sun Jan 06 05:25:16 UTC 2013
[INFO] Final Memory: 101M/241M
[INFO] 
-

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

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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 288 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
-
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: 1357452789133
[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 30 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 

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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 124 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: 14 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)
  
testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testWithNonAccessibleTargetType(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)
  
testInterceptorHashCode(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)
  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] 

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

2013-01-05 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

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


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-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/vfs/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/vfs/core/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_work/build_apache-commons_commons-vfs2-test.html
Work Name: build_apache-commons_commons-vfs2-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 mins 27 secs
Command Line: /opt/maven3/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven3
-
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

Running org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.293 sec
Running org.apache.commons.vfs2.provider.temp.test.TemporaryProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.866 sec
Running org.apache.commons.vfs2.FileExtensionSelectorTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec

Results :

Tests in error: 
  
junit.framework.TestSuite@42d21e87(org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase$HdfsProviderTestSuite):
 
/srv/gump/public/workspace/apache-commons/vfs/core/target/test-classes/test-data/write-tests/file1.txt
 (Permission denied)

Tests run: 1697, Failures: 0, Errors: 1, Skipped: 2

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Commons VFS ... SUCCESS [8.391s]
[INFO] Commons VFS Core .. FAILURE [5:15.490s]
[INFO] Commons VFS Examples .. SKIPPED
[INFO] Commons VFS Distribution .. SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 5:25.122s
[INFO] Finished at: Sun Jan 06 07:20:11 UTC 2013
[INFO] Final Memory: 28M/68M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test (default-test) on 
project commons-vfs2: There are test failures.
[ERROR] 
[ERROR] Please refer to 
/srv/gump/public/workspace/apache-commons/vfs/core/target/surefire-reports for 
the individual test results.
[ERROR] - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn goals -rf :commons-vfs2
-

To subscribe to this information via syndicated feeds:
- RSS: