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

[Gump]

To whom it may engage...

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

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


Full details are available at:

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

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.309 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.096 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: [DBUTILS] Updates for v2.0

[Bill Speirs]

In thinking about it more (I haven't started implementing anything yet), I
don't see why we would want to drop support for positional parameters... we
could easily handle both. (Both in the same piece of SQL might get tricky,
but that's easy enough to detect and throw an exception.)

As for how named parameters should be supported I was thinking of making
QueryRunner into a more fluent style API that would look something like:

qr.query(select * from blah where foo = :foo and bar = :bar).bind(foo,
myFoo).bind(bar, myBar).execute(resultHandler);

This presents the issue that the query method now must return an
intermediate object that holds the state of the sql query (so QueryRunner
itself can remain thread safe). Each call to bind will simply add to that
state and return that object. This makes things a bit more complex, but the
user *should* be none the wiser. If we wanted to use positional parameters
it would simply look like:

qr.query(select * from blah where foo = ? and bar = ?).bind(1,
myFoo).bind(2, myBar).execute(resultHandler);

It is really the change to the interface and the addition of named
parameters that I'd like to promote more than deprecating positional
parameters.

 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.

It was my understanding that the ASF would like to encourage projects to
move towards the org.apache.commons coordinate system for maven. Since my
idea is a somewhat radical change to how DBUtils will be used (fluent style
with bind methods instead of all parameters in one call), I was thinking
this would make for a logical departure from our current maven coordinates.
The only way I know to switch Maven coordinates is to also change the
package names so if someone includes both there won't be collisions and
confusion. Version 2.x would live at org.apache.commons with a package of
o.a.c.dbutils2 and version 1.x still lives at commons-dbutils with
o.a.c.dbutils.

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

I've probably been the most active developer on DBUtils lately, and I've
done very, very little work. DBUtils just works as it stands now in the
1.x branch, so I don't think we'd need much more help there. As for 2.x, my
plan is to implement these changes at ApacheCon NA and try
to recruit others to help [1]... so far, no luck.

Sebb, as always thanks for the feedback! Thoughts?

Bill-

[1] http://wiki.apache.org/apachecon/HackathonNA13



On Sat, Jan 5, 2013 at 3:52 PM, sebb seb...@gmail.com wrote:

 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

[email] mocking of invalid url tests

[Thomas Neidhart]

Hi,

due to the problems some people encountered with some unit tests in
their environment, I modified the tests to mock the invalid url
connection instead.

I did some local tests by adjusting my hosts file, but would like to ask
the people which had test failures earlier to redo them with the updated
code.

Thanks,

Thomas

-
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

[Niall Pemberton]

On Wed, Dec 26, 2012 at 6:32 PM, 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.

Yes, but I think it would have been better to leave the
commons.component.id property unchanged and add a
commons.osgi.symbolicName property to commons math's pom to get what
you wanted for the osgi bundle.

Niall

 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
 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.
 Maybe the best approach is to define commons.project.id and have the
 download plugin use that property instead.  What do others think?

 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.

 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

Re: [Math] Missing links on download page

[Niall Pemberton]

On Sun, Jan 6, 2013 at 4:21 PM, Niall Pemberton
niall.pember...@gmail.com wrote:
 On Wed, Dec 26, 2012 at 6:32 PM, 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.

 Yes, but I think it would have been better to leave the
 commons.component.id property unchanged and add a
 commons.osgi.symbolicName property to commons math's pom to get what
 you wanted for the osgi bundle.

I have attached a patch to MATH-876 which does this - so should
resolve all issues

https://issues.apache.org/jira/browse/MATH-876

 Niall

 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
 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.
 Maybe the best approach is to define commons.project.id and have the
 download plugin use that property instead.  What do others think?

 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.

 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

Re: [commons-parent] drop cobertura

[Niall Pemberton]

On Sat, Dec 29, 2012 at 8:21 PM, Phil Steitz phil.ste...@gmail.com wrote:
 On 12/29/12 10:44 AM, Mark Struberg wrote:
 Any better suggestions for [math]?
 Yes, as I see it there are two options.

 a.) move some parts into a profile

 How exactly would this work?  Can we get rid of stuff that way,
 really?  We can get it to ignore stuff the parent specifies?  Or are
 you talking about yet another profile in the parent?
 b.) create 2 parent pom. One with the infrastructure stuff and one with all 
 the tons of additional goodies only needed for the other projects.

 That seems pretty ugly.  I wonder how bad it would be, actually, to
 just get rid of the parent and define the stuff we actually use /
 need in [math] itself.  I think I have on balance spent more time
 figuring out what was going on in the parent than I would have spent
 just maintaining properties actually used by the components that I
 work on.  Maybe just strip it down to some common properties and
 things like the mailing lists.  At the very least, we should drop
 the reporting section and the one you mention below.



 LieGrue,
 strub


 PS: I find it pretty weird that the commons-parent has a profile to build 
 all the other stuff. This can be done much cleaner in having an own 
 build-aggregator pom which just contains the modules.

 Agreed.  I wonder if anyone ever uses this.  I would be +1 to drop.

I've used it in the past - useful for testing all components with
changes to commons parent or the commons plugin which generates some
of the site pages. Its in a profile, so does no harm.

Niall

 Phil


 - Original Message -
 From: Phil Steitz phil.ste...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc:
 Sent: Saturday, December 29, 2012 7:29 PM
 Subject: Re: [commons-parent] drop cobertura

 On 12/29/12 10:02 AM, Gary Gregory wrote:
  Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
  commons components to Sonar, just do not mess up development for all the
  other components because one class in [math] is not performing acceptably
  for the Cobertura report.
 The problem is that the plugin is bugged and effectively impossible
 to turn off.

 I think the sonar idea is a great one and consistent with what we
 have talked about on and off for years - separating the CI-type
 development reports from the component sites.  As we are about to go
 over the site deployment cliff ;  now is a great time to think
 about losing some weight :)

 I guess an alternative for [math] is to drop commons-parent
 entirely, just grabbing the stuff we need.  Any better suggestions
 for [math]?

 Phil
  Gary


  On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz phil.ste...@gmail.com
 wrote:
  On 12/29/12 9:46 AM, Oliver Heger wrote:
  Am 29.12.2012 09:43, schrieb Luc Maisonobe:
  Hi Phil,

  Le 28/12/2012 21:10, Phil Steitz a écrit :
  On 12/28/12 11:44 AM, Gary Gregory wrote:
  It seems a shame to turn off this feature for ALL
 projects
  because one
  project can't figure out a workaround.
  Can *any* project find a workaround?  Is there *any way* to
 turn
  this thing off?
  What about every project being declared in the aggregator
 project
  Olivier set up in our instance of Sonar
  https://analysis.apache.org/components/index/121254?

  +1

  We could then even disable more reports in the components' poms
  (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
  instance.

  This would provide comprehensive up-to-date statistics for all
  components. It would also be a step forward in making the
  components more uniform.
  +1 - and as yet another bonus, it would reduce wasted infra
  resources duplicating all of the images, etc on all of the
  individual sites and the need to store all of that stuff in svn.

  Phil
  Oliver

  Luc

  Phil
  Gary

  On Dec 28, 2012, at 12:21, Phil Steitz
 phil.ste...@gmail.com
  wrote:

  Any objections to this?  In [math] at least we
 can't seem to
  turn it
  off and it is causing the site build to take
 forever.
  Thanks!

  Phil


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


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


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


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

Re: [email] mocking of invalid url tests

[Phil Steitz]

On 1/6/13 7:09 AM, Thomas Neidhart wrote:
 Hi,

 due to the problems some people encountered with some unit tests in
 their environment, I modified the tests to mock the invalid url
 connection instead.

 I did some local tests by adjusting my hosts file, but would like to ask
 the people which had test failures earlier to redo them with the updated
 code.

Tests in trunk run clean for me now.

Thanks!

Phil

 Thanks,

 Thomas

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




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

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

[Gump]

To whom it may engage...

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

Project commons-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: 4 mins 46 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.267 sec
Running org.apache.commons.vfs2.provider.temp.test.TemporaryProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.793 sec
Running org.apache.commons.vfs2.FileExtensionSelectorTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec

Results :

Tests in error: 
  
junit.framework.TestSuite@4fb7b156(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.685s]
[INFO] Commons VFS Core .. FAILURE [4:34.239s]
[INFO] Commons VFS Examples .. SKIPPED
[INFO] Commons VFS Distribution .. SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 4:44.185s
[INFO] Finished at: Sun Jan 06 19:04:11 UTC 2013
[INFO] Final Memory: 29M/69M
[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:
- 

Re: [email] mocking of invalid url tests

[Gary Gregory]

Tests OK for me now when before it did not due to Cox highjacking the
.invalid domain.

Thank you,
Gary


On Sun, Jan 6, 2013 at 12:44 PM, Phil Steitz phil.ste...@gmail.com wrote:

 On 1/6/13 7:09 AM, Thomas Neidhart wrote:
  Hi,
 
  due to the problems some people encountered with some unit tests in
  their environment, I modified the tests to mock the invalid url
  connection instead.
 
  I did some local tests by adjusting my hosts file, but would like to ask
  the people which had test failures earlier to redo them with the updated
  code.

 Tests in trunk run clean for me now.

 Thanks!

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


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




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

[VOTE] Release of Commons Email 1.3 based on RC7

[Thomas Neidhart]

Hi,

I would like to call a vote for releasing commons-email-1.3 based on RC7.

This release candidate has the following changes compared to RC6:

+) added missing @since tags in class Email
+) update links in release notes
+) change unit tests with invalid URLs to be more reliable (with the
   help of powermock: use a mocked URL object which will always fail
   when trying to open a connection to it)

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-104/org/apache/commons/commons-email/1.3/

The tag:
https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC7/

The site:
http://people.apache.org/builds/commons/email/1.3/RC7/

Additional Notes:

o the download page and api links to older releases only work on
  the published site and will be corrected after release.

Please take a look at the commons-email-1.3 artifacts and vote!


[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...


Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

RE: [VFS] Support for File System Roots?

[Roger L. Whitcomb]

I'm actually working on a similar project to make a new version of the
Apache Pivot File Browser to use VFS.  So, I'd also be interested to see
what suggestions the developers here have.  

~Roger Whitcomb

-Original Message-
From: Mark Fortner [mailto:phidia...@gmail.com] 
Sent: Friday, December 28, 2012 11:54 AM
To: Commons Developers List
Subject: Re: [VFS] Support for File System Roots?

Hi Gary,
This would be per operating system.  So, if I call
*RootFactory.getRoot(RootNames.HOME)
*from a Linux box, that would resolve to */home/username*, on a
Windows box that might be */Users/username*.  It would be driven by
the *
System.getProperty(user.home)* variable.  The other roots, are OS
dependent and are subdirectories of the home directory.  You might also
have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
let you get the value for Linux, even if you aren't on a Linux box.

The URIs might look like /Documents which would resolve to
file:///home/username/Documents.

This came up because I'm reworking a Swing file manager using JavaFX and
I wanted to clean up the API some and minimize any VFS specific
workarounds I was doing.

Cheers,

Mark



On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
garydgreg...@gmail.comwrote:

 Would this only be for Windows? What do URIs look like?

 Gary

 On Dec 28, 2012, at 14:18, Mark Fortner phidia...@gmail.com wrote:

  I was wondering if there were any plans (or currently any way) to 
  support File System Roots.  In addition to the standard sorts of 
  roots, there are roots like your home directory, the Documents, 
  Photos, Music, Downloads, etc.
 
  At a minimum it would be useful to have an Enum of the different
 directory
  names, with some way of resolving them.  Something like:
 
  FileObject root = RootFactory.getRoot(RootNames.HOME);
 
  and
 
  MapString, FileObject rootMap = RootFactory.getRoots();
 
 
  Cheers,
 
  Mark

 -
 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: [VFS] Support for File System Roots?

[Mark Fortner]

Gary,
The File#getRoots() method that you mentioned gets the file system roots
and not user-specific directories like Documents, Downloads, Photos, Music,
etc.

I ended up creating a solution with maps of directories for each operating
system (or relevant OS version in the case of Windows).  I also implemented
a solution for resolving ~ as the home directory in URLs.  I can check
these into my project and send you the URLs for the files if you're
interested.

Cheers,

Mark



On Sun, Jan 6, 2013 at 3:18 PM, Roger L. Whitcomb roger.whitc...@actian.com
 wrote:

 I'm actually working on a similar project to make a new version of the
 Apache Pivot File Browser to use VFS.  So, I'd also be interested to see
 what suggestions the developers here have.

 ~Roger Whitcomb

 -Original Message-
 From: Mark Fortner [mailto:phidia...@gmail.com]
 Sent: Friday, December 28, 2012 11:54 AM
 To: Commons Developers List
 Subject: Re: [VFS] Support for File System Roots?

 Hi Gary,
 This would be per operating system.  So, if I call
 *RootFactory.getRoot(RootNames.HOME)
 *from a Linux box, that would resolve to */home/username*, on a
 Windows box that might be */Users/username*.  It would be driven by
 the *
 System.getProperty(user.home)* variable.  The other roots, are OS
 dependent and are subdirectories of the home directory.  You might also
 have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
 let you get the value for Linux, even if you aren't on a Linux box.

 The URIs might look like /Documents which would resolve to
 file:///home/username/Documents.

 This came up because I'm reworking a Swing file manager using JavaFX and
 I wanted to clean up the API some and minimize any VFS specific
 workarounds I was doing.

 Cheers,

 Mark



 On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
 garydgreg...@gmail.comwrote:

  Would this only be for Windows? What do URIs look like?
 
  Gary
 
  On Dec 28, 2012, at 14:18, Mark Fortner phidia...@gmail.com wrote:
 
   I was wondering if there were any plans (or currently any way) to
   support File System Roots.  In addition to the standard sorts of
   roots, there are roots like your home directory, the Documents,
   Photos, Music, Downloads, etc.
  
   At a minimum it would be useful to have an Enum of the different
  directory
   names, with some way of resolving them.  Something like:
  
   FileObject root = RootFactory.getRoot(RootNames.HOME);
  
   and
  
   MapString, FileObject rootMap = RootFactory.getRoots();
  
  
   Cheers,
  
   Mark
 
  -
  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: [VFS] Support for File System Roots?

[Mark Fortner]

Sorry, that should have read *FileSystem.listRoots()*.

Cheers,

Mark



On Sun, Jan 6, 2013 at 4:50 PM, Mark Fortner phidia...@gmail.com wrote:

 Gary,
 The File#getRoots() method that you mentioned gets the file system roots
 and not user-specific directories like Documents, Downloads, Photos, Music,
 etc.

 I ended up creating a solution with maps of directories for each operating
 system (or relevant OS version in the case of Windows).  I also implemented
 a solution for resolving ~ as the home directory in URLs.  I can check
 these into my project and send you the URLs for the files if you're
 interested.

 Cheers,

 Mark



 On Sun, Jan 6, 2013 at 3:18 PM, Roger L. Whitcomb 
 roger.whitc...@actian.com wrote:

 I'm actually working on a similar project to make a new version of the
 Apache Pivot File Browser to use VFS.  So, I'd also be interested to see
 what suggestions the developers here have.

 ~Roger Whitcomb

 -Original Message-
 From: Mark Fortner [mailto:phidia...@gmail.com]
 Sent: Friday, December 28, 2012 11:54 AM
 To: Commons Developers List
 Subject: Re: [VFS] Support for File System Roots?

 Hi Gary,
 This would be per operating system.  So, if I call
 *RootFactory.getRoot(RootNames.HOME)
 *from a Linux box, that would resolve to */home/username*, on a
 Windows box that might be */Users/username*.  It would be driven by
 the *
 System.getProperty(user.home)* variable.  The other roots, are OS
 dependent and are subdirectories of the home directory.  You might also
 have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
 let you get the value for Linux, even if you aren't on a Linux box.

 The URIs might look like /Documents which would resolve to
 file:///home/username/Documents.

 This came up because I'm reworking a Swing file manager using JavaFX and
 I wanted to clean up the API some and minimize any VFS specific
 workarounds I was doing.

 Cheers,

 Mark



 On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
 garydgreg...@gmail.comwrote:

  Would this only be for Windows? What do URIs look like?
 
  Gary
 
  On Dec 28, 2012, at 14:18, Mark Fortner phidia...@gmail.com wrote:
 
   I was wondering if there were any plans (or currently any way) to
   support File System Roots.  In addition to the standard sorts of
   roots, there are roots like your home directory, the Documents,
   Photos, Music, Downloads, etc.
  
   At a minimum it would be useful to have an Enum of the different
  directory
   names, with some way of resolving them.  Something like:
  
   FileObject root = RootFactory.getRoot(RootNames.HOME);
  
   and
  
   MapString, FileObject rootMap = RootFactory.getRoots();
  
  
   Cheers,
  
   Mark
 
  -
  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

[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 121 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-07012013.jar:/srv/gump/public/workspace/junit/dist/junit-dep-07012013.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

[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 290 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-07012013.jar:/srv/gump/public/workspace/junit/dist/junit-dep-07012013.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-email (in module apache-commons) failed

[Gump]

To whom it may engage...

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

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


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/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-email-*[0-9T].jar] identifier set to project 
name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/email/pom.xml
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/gump_work/build_apache-commons_commons-email.html
Work Name: build_apache-commons_commons-email (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 mins 2 secs
Command Line: /opt/maven2/bin/mvn --batch-mode 
-Dmaven.jar.mail=/srv/gump/packages/javamail-1.4/mail.jar --settings 
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/email]
M2_HOME: /opt/maven2
-
at java.lang.Short.parseShort(Short.java:119)
at java.lang.Short.parseShort(Short.java:143)
at 
org.powermock.modules.junit4.common.internal.impl.VersionCompatibility.getJUnitVersion(VersionCompatibility.java:40)
at 
org.powermock.modules.junit4.PowerMockRunner.init(PowerMockRunner.java:31)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at 
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
at 
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:250)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
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)


Results :

Tests in error: 
  initializationError(org.apache.commons.mail.MultiPartEmailTest): Value out of 
range. Value:07012013 Radix:10
  initializationError(org.apache.commons.mail.ImageHtmlEmailTest): Value out of 
range. Value:07012013 Radix:10
  initializationError(org.apache.commons.mail.HtmlEmailTest): Value out of 
range. Value:07012013 Radix:10

Tests run: 88, Failures: 0, Errors: 3, Skipped: 0

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

Please refer to 
/srv/gump/public/workspace/apache-commons/email/target/surefire-reports for the 
individual test results.
[INFO] 

Re: [DBUTILS] Updates for v2.0

[sebb]

On 6 January 2013 14:50, Bill Speirs bill.spe...@gmail.com wrote:
 In thinking about it more (I haven't started implementing anything yet), I
 don't see why we would want to drop support for positional parameters... we
 could easily handle both. (Both in the same piece of SQL might get tricky,
 but that's easy enough to detect and throw an exception.)

 As for how named parameters should be supported I was thinking of making
 QueryRunner into a more fluent style API that would look something like:

 qr.query(select * from blah where foo = :foo and bar = :bar).bind(foo,
 myFoo).bind(bar, myBar).execute(resultHandler);

 This presents the issue that the query method now must return an
 intermediate object that holds the state of the sql query (so QueryRunner
 itself can remain thread safe). Each call to bind will simply add to that
 state and return that object. This makes things a bit more complex, but the
 user *should* be none the wiser.

Or you could use a Map to hold the names and values.

 If we wanted to use positional parameters
 it would simply look like:

 qr.query(select * from blah where foo = ? and bar = ?).bind(1,
 myFoo).bind(2, myBar).execute(resultHandler);

Here one could use a List.

 It is really the change to the interface and the addition of named
 parameters that I'd like to promote more than deprecating positional
 parameters.

 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.

 It was my understanding that the ASF would like to encourage projects to
 move towards the org.apache.commons coordinate system for maven.

It would simplify Nexus maintenance.
But the extra work involved in setting up non-standard Nexus projects
is a one-off for one organisation (the ASF), whereas a groupId change
would require extra work by all downstream users, and anyway most of
these have been set up already.

So yes, if we need to change package name for reasons of binary
compatibility, we should take the opportuntity to change the group id.
But changing the group id for the sake of it does not make any sense,
particularly for relatively low-level library projects such as
Commons.

 Since my
 idea is a somewhat radical change to how DBUtils will be used (fluent style
 with bind methods instead of all parameters in one call), I was thinking
 this would make for a logical departure from our current maven coordinates.

If the entire API is to change, then I agree one might as well treat
it as a completerly new library and change groupId/package name.
Users could either stick with the current design or rewrite to use the
new design.
The risk is that some end-users won't want to switch, and may drift
way from the orginal library if it is not being maintained.

But if the intent is only to add some new elements to the API, doing
so in an incremental, binary-compatible way would allow endusers much
more flexibility in upgrading.

 The only way I know to switch Maven coordinates is to also change the
 package names so if someone includes both there won't be collisions and
 confusion. Version 2.x would live at org.apache.commons with a package of
 o.a.c.dbutils2 and version 1.x still lives at commons-dbutils with
 o.a.c.dbutils.

Yes, that's necessary. Both have to change together.

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

 I've probably been the most active developer on DBUtils lately, and I've
 done very, very little work. DBUtils just works as it stands now in the
 1.x branch, so I don't think we'd need much more help there.

There are some outstanding JIRA issues (mostly enhancement requests).

Do any of these need to be addressed to bring 1.x up to date?

  As for 2.x, my
 plan is to implement these changes at ApacheCon NA and try
 to recruit others to help [1]... so far, no luck.

 Sebb, as always thanks for the feedback! Thoughts?

It would be useful to show some examples of how the fluent style
compares with the existing style before proceeding.

At the moment I'm not convinced that it would be a major benefit.

 Bill-

 [1] http://wiki.apache.org/apachecon/HackathonNA13



 On Sat, Jan 5, 2013 at 3:52 PM, sebb seb...@gmail.com wrote:

 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 

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

[Gump]

To whom it may engage...

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

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 121 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 25 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 24 seconds
[INFO] Finished at: Mon Jan 07 05:02:13 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

[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 312 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: 52 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: 50 seconds
[INFO] Finished at: Mon Jan 07 05:41:30 UTC 2013
[INFO] Final Memory: 99M/237M
[INFO] 
-

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

Re: [VFS] Support for File System Roots?

[Gary Gregory]

Ok, that sounds interesting. Can you give us some examples? I sounds like
it makes sense for file:// only. Did you have it in mind for other file
systems?

Should the treatment of '~' be optional? Is there a chance of it being
confused with any kind of legal file reference on any OS?

Gary


On Sun, Jan 6, 2013 at 7:50 PM, Mark Fortner phidia...@gmail.com wrote:

 Gary,
 The File#getRoots() method that you mentioned gets the file system roots
 and not user-specific directories like Documents, Downloads, Photos, Music,
 etc.

 I ended up creating a solution with maps of directories for each operating
 system (or relevant OS version in the case of Windows).  I also implemented
 a solution for resolving ~ as the home directory in URLs.  I can check
 these into my project and send you the URLs for the files if you're
 interested.

 Cheers,

 Mark



 On Sun, Jan 6, 2013 at 3:18 PM, Roger L. Whitcomb 
 roger.whitc...@actian.com
  wrote:

  I'm actually working on a similar project to make a new version of the
  Apache Pivot File Browser to use VFS.  So, I'd also be interested to see
  what suggestions the developers here have.
 
  ~Roger Whitcomb
 
  -Original Message-
  From: Mark Fortner [mailto:phidia...@gmail.com]
  Sent: Friday, December 28, 2012 11:54 AM
  To: Commons Developers List
  Subject: Re: [VFS] Support for File System Roots?
 
  Hi Gary,
  This would be per operating system.  So, if I call
  *RootFactory.getRoot(RootNames.HOME)
  *from a Linux box, that would resolve to */home/username*, on a
  Windows box that might be */Users/username*.  It would be driven by
  the *
  System.getProperty(user.home)* variable.  The other roots, are OS
  dependent and are subdirectories of the home directory.  You might also
  have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
  let you get the value for Linux, even if you aren't on a Linux box.
 
  The URIs might look like /Documents which would resolve to
  file:///home/username/Documents.
 
  This came up because I'm reworking a Swing file manager using JavaFX and
  I wanted to clean up the API some and minimize any VFS specific
  workarounds I was doing.
 
  Cheers,
 
  Mark
 
 
 
  On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
  garydgreg...@gmail.comwrote:
 
   Would this only be for Windows? What do URIs look like?
  
   Gary
  
   On Dec 28, 2012, at 14:18, Mark Fortner phidia...@gmail.com wrote:
  
I was wondering if there were any plans (or currently any way) to
support File System Roots.  In addition to the standard sorts of
roots, there are roots like your home directory, the Documents,
Photos, Music, Downloads, etc.
   
At a minimum it would be useful to have an Enum of the different
   directory
names, with some way of resolving them.  Something like:
   
FileObject root = RootFactory.getRoot(RootNames.HOME);
   
and
   
MapString, FileObject rootMap = RootFactory.getRoots();
   
   
Cheers,
   
Mark
  
   -
   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
 
 




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

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

[Gump]

To whom it may engage...

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

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 290 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
 -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: 28 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
-
Running org.apache.commons.dbutils.handlers.BeanListHandlerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec
Running org.apache.commons.dbutils.handlers.BeanMapHandlerTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.544 sec
Running org.apache.commons.dbutils.handlers.KeyedHandlerTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.dbutils.ProxyFactoryTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.121 sec
Running org.apache.commons.dbutils.wrappers.SqlNullCheckedResultSetTest
Tests run: 43, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec
Running org.apache.commons.dbutils.wrappers.StringTrimmedResultSetTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.dbutils.BaseResultSetHandlerTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.dbutils.ResultSetIteratorTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.dbutils.BeanProcessorTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.dbutils.BasicRowProcessorTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
Running org.apache.commons.dbutils.QueryLoaderTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.dbutils.DbUtilsTest
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.168 sec
Running org.apache.commons.dbutils.AsyncQueryRunnerTest
Tests run: 32, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.448 sec  
FAILURE!
Running org.apache.commons.dbutils.QueryRunnerTest
Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.243 sec
Running org.apache.commons.dbutils.GenerousBeanProcessorTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec

Results :

Failed tests:   
testInsertUsesGivenQueryRunner(org.apache.commons.dbutils.AsyncQueryRunnerTest):
 (..)

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports for 
the individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 27 seconds
[INFO] Finished at: Mon Jan 07 06:30:49 UTC 2013
[INFO] Final Memory: 42M/101M
[INFO] 
-

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

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

[Gump]

To whom it may engage...

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

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 126 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: 15 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: 
  
testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInvocationImplementation(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)
  
testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerEquals(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)
  
testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorHashCode(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)
  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

[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,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-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: 4 mins 58 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.253 sec
Running org.apache.commons.vfs2.provider.temp.test.TemporaryProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.862 sec
Running org.apache.commons.vfs2.FileExtensionSelectorTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec

Results :

Tests in error: 
  
junit.framework.TestSuite@6dfec65(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.660s]
[INFO] Commons VFS Core .. FAILURE [4:45.846s]
[INFO] Commons VFS Examples .. SKIPPED
[INFO] Commons VFS Distribution .. SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 4:55.814s
[INFO] Finished at: Mon Jan 07 07:32:01 UTC 2013
[INFO] Final Memory: 29M/71M
[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