[GUMP@vmgump]: Project commons-id (in module commons-sandbox) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-id has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 116 runs.
The current state of this project is 'Failed', with reason 'Missing Build
Outputs'.
For reference only, the following projects are affected by this:
- commons-id : Commons Identifier Package
Full details are available at:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/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-id-10052012.jar] identifier set to project
name
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/commons-sandbox/id/gump_mvn_settings.xml
-DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/id/pom.xml
-INFO- Failed with reason missing build outputs
-ERROR- Missing Output:
/srv/gump/public/workspace/commons-sandbox/id/target/commons-id-10052012.jar
-ERROR- See Directory Listing Work for Missing Outputs
-INFO- Project Reports in:
/srv/gump/public/workspace/commons-sandbox/id/target/surefire-reports
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/gump_work/build_commons-sandbox_commons-id.html
Work Name: build_commons-sandbox_commons-id (Type: Build)
Work ended in a state of : Success
Elapsed: 19 secs
Command Line: /opt/maven2/bin/mvn --batch-mode
-Dmaven.final.name=commons-id-10052012 --settings
/srv/gump/public/workspace/commons-sandbox/id/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/commons-sandbox/id]
M2_HOME: /opt/maven2
-
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.id.serial.AlphanumericGeneratorTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec
Running org.apache.commons.id.uuid.state.InMemoryStateImplTest
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
FAILURE!
Running org.apache.commons.id.serial.LongGeneratorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
Running org.apache.commons.id.random.SessionIdGeneratorTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.423 sec
Running
org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.472 sec
Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.id.uuid.VersionFourGeneratorTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.131 sec
Running org.apache.commons.id.uuid.state.NodeTest
Tests run: 8, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.018 sec
FAILURE!
Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.id.uuid.task.UUIDTaskTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec
Running org.apache.commons.id.serial.NumericGeneratorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Results :
Failed tests:
testLoad(org.apache.commons.id.uuid.state.InMemoryStateImplTest)
Tests in error:
testGetUUIDTime(org.apache.commons.id.uuid.state.NodeTest)
testGetLastTimestamp(org.apache.commons.id.uuid.state.NodeTest)
testNodebyteArray(org.apache.commons.id.uuid.state.NodeTest)
Tests run: 121, Failures: 1, Errors: 3, Skipped: 0
[ERROR] There are test failures.
Please refer to
/srv/gump/public/workspace/commons-sandbox/id/target/surefire-reports for the
individual test results.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/srv/gump/public/workspace/commons-sandbox/id/target/commons-id-1.0-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 18 seconds
[INFO] Finished at: Thu May 10 07:05:23 UTC 2012
[INFO] Final Memory: 30M/72M
[INFO]
-
To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/rss.xml
- Atom:
[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 155 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: 19 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.143 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.06 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]
[GUMP@vmgump]: Project commons-jelly-tags-jmx (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-jmx has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 31 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jmx : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-jelly-tags-jmx-10052012.jar] identifier set to project name -ERROR- Output with id mx4j-jmx was not found in project mx4j -ERROR- Unhandled Property: maven.jar.mx4j-jmx on: Maven1 on Project:commons-jelly-tags-jmx -DEBUG- Dependency on mx4j exists, no need to add for property maven.jar.mx4j-jmx. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -DEBUG- (Apache Gump generated) Apache Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/gump_work/build_commons-jelly_commons-jelly-tags-jmx.html Work Name: build_commons-jelly_commons-jelly-tags-jmx (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx] - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-1.1-SNAPSHOT.jar may be out of date! The build cannot continue because of the following unsatisfied dependency: mx4j-jmx-1.1.1.jar; path override doesn't exist: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/*Unset* Total time: 1 seconds Finished at: Thu May 10 07:15:28 UTC 2012 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1310052012, vmgump.apache.org:vmgump:1310052012 Gump E-mail Identifier (unique within run) #65. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: Does Apache already have access to JSR 223 TCK
Do ya'll know the answer to this? -- Forwarded message -- From: Dishara Wijewardana ddwijeward...@gmail.com Date: Thu, May 10, 2012 at 9:50 AM Subject: Does Apache already have access to JSR 223 TCK To: Velocity Developers List d...@velocity.apache.org, Claude Brisson cla...@renegat.net Hi all, I saw some mail archives that Apache BSF has requested/had intention for requesting for the JSR 223 TCK. If they have that from Apache point of view, I think we can also use that. It is really helpful when implementing the spec. (specially if the TCK code is available, it is very efficient in implementing it). -- Thanks /Dishara - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[functor] Remove duplicated equals() methods
Hi all, While I am still trying to find time to work on a proposal for enhancements in the generators API in [functor] (https://issues.apache.org/jira/browse/FUNCTOR-14), I'm reviewing other pending issues, including the one regarding test coverage. The comparators API seemed to be lacking tests for some decision branches. But looking closely at the code, I realized that there were two equals code in some comparator functors. Then I set up a Sonar instance to scan the code, and found that it is common in many other parts of the code (http://66.228.56.222/sonar/drilldown/violations/org.apache.commons:commons-functor?severity=CRITICAL). Does anybody know if there is some reason for having both equals(Object that) and equals(SomeFunctor? that)? I think we could merge both methods in only one. The Generators in [functor] have only one equals() method, and compares against this, uses instanceof, etc. I had a quick look on [math3] and [lang3], and looks like they both use only one equals() method, compares against this, uses instaceof, etc. If there is no objection here, I could create a patch for this in Jira, merging both equals() methods in one :-) Then after this I will proceed writing tests to increase the test coverage (https://issues.apache.org/jira/browse/FUNCTOR-12). Thanks in advance! Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [functor] Remove duplicated equals() methods
On Thu, May 10, 2012 at 1:27 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: Hi all, While I am still trying to find time to work on a proposal for enhancements in the generators API in [functor] (https://issues.apache.org/jira/browse/FUNCTOR-14), I'm reviewing other pending issues, including the one regarding test coverage. The comparators API seemed to be lacking tests for some decision branches. But looking closely at the code, I realized that there were two equals code in some comparator functors. Then I set up a Sonar instance to scan the code, and found that it is common in many other parts of the code (http://66.228.56.222/sonar/drilldown/violations/org.apache.commons:commons-functor?severity=CRITICAL). Does anybody know if there is some reason for having both equals(Object that) and equals(SomeFunctor? that)? I think we could merge both methods in only one. The Generators in [functor] have only one equals() method, and compares against this, uses instanceof, etc. I had a quick look on [math3] and [lang3], and looks like they both use only one equals() method, compares against this, uses instaceof, etc. If there is no objection here, I could create a patch for this in Jira, merging both equals() methods in one :-) Then after this I will proceed writing tests to increase the test coverage (https://issues.apache.org/jira/browse/FUNCTOR-12). Bruno, As far as I know this pattern was introduced by one of [functor]'s original authors and must simply have been his preference. Personally I agree that this is not what your average Java developer probably expects to see in your average Java codebase, and would support combining these methods. This is documented at [1] and filed at [2] (where your earlier comment is valid, and is also mentioned at [1], but doesn't IMHO pertain specifically to this JIRA issue). Regards, Matt [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-11 Thanks in advance! Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - 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: [functor] Remove duplicated equals() methods
On 05/10/2012 03:38 PM, Matt Benson wrote: On Thu, May 10, 2012 at 1:27 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: Hi all, While I am still trying to find time to work on a proposal for enhancements in the generators API in [functor] (https://issues.apache.org/jira/browse/FUNCTOR-14), I'm reviewing other pending issues, including the one regarding test coverage. The comparators API seemed to be lacking tests for some decision branches. But looking closely at the code, I realized that there were two equals code in some comparator functors. Then I set up a Sonar instance to scan the code, and found that it is common in many other parts of the code (http://66.228.56.222/sonar/drilldown/violations/org.apache.commons:commons-functor?severity=CRITICAL). Does anybody know if there is some reason for having both equals(Object that) and equals(SomeFunctor? that)? I think we could merge both methods in only one. The Generators in [functor] have only one equals() method, and compares against this, uses instanceof, etc. I had a quick look on [math3] and [lang3], and looks like they both use only one equals() method, compares against this, uses instaceof, etc. If there is no objection here, I could create a patch for this in Jira, merging both equals() methods in one :-) Then after this I will proceed writing tests to increase the test coverage (https://issues.apache.org/jira/browse/FUNCTOR-12). Bruno, As far as I know this pattern was introduced by one of [functor]'s original authors and must simply have been his preference. Personally I agree that this is not what your average Java developer probably expects to see in your average Java codebase, and would support combining these methods. This is documented at [1] and filed at [2] (where your earlier comment is valid, and is also mentioned at [1], but doesn't IMHO pertain specifically to this JIRA issue). Regards, Matt [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-11 Thanks in advance! Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org Hi Matt, Thanks for your speedy reply and for sending me the links. You are right indeed, there is already an issue filled for this, and my comment is not pertinent to that issue :-) The comment in question refers to the item - why are equals, hashCode and toString defined in the Functor interface? from [1]. Maybe we should create a separate issue for that, WDYT? I will use FUNCTOR-11 to attach my patch combining the equals() methods. Regarding the Sanity Check Wiki entry, do you think we should add Remove @author tags too? I believe it has been decided in Apache Commons to stop using this tag (I can't remember if it is only the @author tag, or there are other tags too). BTW, I filled another issue [2] today with a patch that fixes some minor checkstyle errors in [functor]. Thanks again! -- Bruno P. Kinoshita http://www.kinoshita.eti.br http://www.tupilabs.com [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-16 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [functor] Remove duplicated equals() methods
On Thu, May 10, 2012 at 2:09 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: On 05/10/2012 03:38 PM, Matt Benson wrote: On Thu, May 10, 2012 at 1:27 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: Hi all, While I am still trying to find time to work on a proposal for enhancements in the generators API in [functor] (https://issues.apache.org/jira/browse/FUNCTOR-14), I'm reviewing other pending issues, including the one regarding test coverage. The comparators API seemed to be lacking tests for some decision branches. But looking closely at the code, I realized that there were two equals code in some comparator functors. Then I set up a Sonar instance to scan the code, and found that it is common in many other parts of the code (http://66.228.56.222/sonar/drilldown/violations/org.apache.commons:commons-functor?severity=CRITICAL). Does anybody know if there is some reason for having both equals(Object that) and equals(SomeFunctor? that)? I think we could merge both methods in only one. The Generators in [functor] have only one equals() method, and compares against this, uses instanceof, etc. I had a quick look on [math3] and [lang3], and looks like they both use only one equals() method, compares against this, uses instaceof, etc. If there is no objection here, I could create a patch for this in Jira, merging both equals() methods in one :-) Then after this I will proceed writing tests to increase the test coverage (https://issues.apache.org/jira/browse/FUNCTOR-12). Bruno, As far as I know this pattern was introduced by one of [functor]'s original authors and must simply have been his preference. Personally I agree that this is not what your average Java developer probably expects to see in your average Java codebase, and would support combining these methods. This is documented at [1] and filed at [2] (where your earlier comment is valid, and is also mentioned at [1], but doesn't IMHO pertain specifically to this JIRA issue). Regards, Matt [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-11 Thanks in advance! Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org Hi Matt, Thanks for your speedy reply and for sending me the links. You are right indeed, there is already an issue filled for this, and my comment is not pertinent to that issue :-) The comment in question refers to the item - why are equals, hashCode and toString defined in the Functor interface? from [1]. Maybe we should create a separate issue for that, WDYT? I'm not necessarily of the opinion that this is wrong, hence my comment that a [VOTE] or [POLL] would IMHO be more appropriate than a JIRA issue at this time. Your JIRA comment mentions the example of java.util.Map, and given that I can also cite java.lang.annotation.Annotation. In light of these I would be inclined to vote in favor of letting these javadoc-hosting method declarations remain, unless someone comes along with a convincing argument. I will use FUNCTOR-11 to attach my patch combining the equals() methods. Regarding the Sanity Check Wiki entry, do you think we should add Remove @author tags too? I believe it has been decided in Apache Commons to stop using this tag (I can't remember if it is only the @author tag, or there are other tags too). +1 here to simply open a JIRA issue, no need to discuss in the wiki. BTW, I filled another issue [2] today with a patch that fixes some minor checkstyle errors in [functor]. Thanks again! Thank you! Matt -- Bruno P. Kinoshita http://www.kinoshita.eti.br http://www.tupilabs.com [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-16 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [functor] Remove duplicated equals() methods
Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - Original Message - From: Matt Benson gudnabr...@gmail.com To: Bruno P. Kinoshita brunodepau...@yahoo.com.br Cc: Commons Developers List dev@commons.apache.org Sent: Thursday, 10 May 2012 4:44 PM Subject: Re: [functor] Remove duplicated equals() methods On Thu, May 10, 2012 at 2:09 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: On 05/10/2012 03:38 PM, Matt Benson wrote: On Thu, May 10, 2012 at 1:27 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: Hi all, While I am still trying to find time to work on a proposal for enhancements in the generators API in [functor] (https://issues.apache.org/jira/browse/FUNCTOR-14), I'm reviewing other pending issues, including the one regarding test coverage. The comparators API seemed to be lacking tests for some decision branches. But looking closely at the code, I realized that there were two equals code in some comparator functors. Then I set up a Sonar instance to scan the code, and found that it is common in many other parts of the code (http://66.228.56.222/sonar/drilldown/violations/org.apache.commons:commons-functor?severity=CRITICAL). Does anybody know if there is some reason for having both equals(Object that) and equals(SomeFunctor? that)? I think we could merge both methods in only one. The Generators in [functor] have only one equals() method, and compares against this, uses instanceof, etc. I had a quick look on [math3] and [lang3], and looks like they both use only one equals() method, compares against this, uses instaceof, etc. If there is no objection here, I could create a patch for this in Jira, merging both equals() methods in one :-) Then after this I will proceed writing tests to increase the test coverage (https://issues.apache.org/jira/browse/FUNCTOR-12). Bruno, As far as I know this pattern was introduced by one of [functor]'s original authors and must simply have been his preference. Personally I agree that this is not what your average Java developer probably expects to see in your average Java codebase, and would support combining these methods. This is documented at [1] and filed at [2] (where your earlier comment is valid, and is also mentioned at [1], but doesn't IMHO pertain specifically to this JIRA issue). Regards, Matt [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-11 Thanks in advance! Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org Hi Matt, Thanks for your speedy reply and for sending me the links. You are right indeed, there is already an issue filled for this, and my comment is not pertinent to that issue :-) The comment in question refers to the item - why are equals, hashCode and toString defined in the Functor interface? from [1]. Maybe we should create a separate issue for that, WDYT? I'm not necessarily of the opinion that this is wrong, hence my comment that a [VOTE] or [POLL] would IMHO be more appropriate than a JIRA issue at this time. Your JIRA comment mentions the example of java.util.Map, and given that I can also cite java.lang.annotation.Annotation. In light of these I would be inclined to vote in favor of letting these javadoc-hosting method declarations remain, unless someone comes along with a convincing argument. I will use FUNCTOR-11 to attach my patch combining the equals() methods. Regarding the Sanity Check Wiki entry, do you think we should add Remove @author tags too? I believe it has been decided in Apache Commons to stop using this tag (I can't remember if it is only the @author tag, or there are other tags too). +1 here to simply open a JIRA issue, no need to discuss in the wiki. BTW, I filled another issue [2] today with a patch that fixes some minor checkstyle errors in [functor]. Thanks again! Thank you! Matt -- Bruno P. Kinoshita http://www.kinoshita.eti.br http://www.tupilabs.com [1] http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. [2] https://issues.apache.org/jira/browse/FUNCTOR-16 Hi Matt, +1 here to simply open a JIRA issue, no need to discuss in the wiki. Thanks, I will open a JIRA issue to remove @author tags. I'm not necessarily of the opinion that this is wrong, hence my comment that a [VOTE] or [POLL] would IMHO be more appropriate than a JIRA issue at this time. Your JIRA comment mentions the example of java.util.Map, and given that I can also cite java.lang.annotation.Annotation. In light of these I would be inclined to vote in favor of letting these javadoc-hosting
[GUMP@vmgump]: Project commons-exec-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-exec-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-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-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/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 24 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - Running org.apache.commons.exec.util.StringUtilTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.exec.util.MapUtilTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.exec.DefaultExecutorTest FOO.. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2012 millis; below is its output Process timed out and was killed. Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8036 millis; above is its output Processes terminated: 6 killed: 0 Multiplier: 1 MaxRetries: 180 Elapsed (avg ms): 1008 Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.029 ms Process completed in 2010 millis; below is its output Process timed out and was killed by watchdog. gdal_translate HDF5:/home/kk/grass/data/4404.he5://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.968 sec FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, 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/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 23 seconds [INFO] Finished at: Fri May 11 01:54:32 UTC 2012 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1311052012, vmgump.apache.org:vmgump:1311052012 Gump E-mail Identifier (unique within run) #15. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
and has been outstanding for 68 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: 49 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
package
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1336703824567
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel)
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel/image)
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel/item)
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
error:
[GUMP@vmgump]: Project commons-graph (in module commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-graph has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 109 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-graph : Apache commons sandbox Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-graph/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-graph-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/commons-sandbox/graph/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/graph/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-graph/gump_work/build_commons-sandbox_commons-graph.html Work Name: build_commons-sandbox_commons-graph (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/commons-sandbox/graph/gump_mvn_settings.xml install [Working Directory: /srv/gump/public/workspace/commons-sandbox/graph] M2_HOME: /opt/maven2 - [ERROR] /srv/gump/public/workspace/commons-sandbox/graph/src/main/java/org/apache/commons/graph/CommonsGraph.java:[215,61] withConnections(org.apache.commons.graph.builder.GraphConnectionjava.lang.Object,java.lang.Object) in org.apache.commons.graph.builder.LinkedConnectionBuilderjava.lang.Object,java.lang.Object,org.apache.commons.graph.model.UndirectedMutableGraphV,E cannot be applied to (org.apache.commons.graph.builder.GraphConnectionV,E) [ERROR] /srv/gump/public/workspace/commons-sandbox/graph/src/main/java/org/apache/commons/graph/flow/DefaultMaxFlowAlgorithmSelector.java:[75,43] cannot find symbol symbol : method applyingDepthFirstSearch(org.apache.commons.graph.flow.FlowNetworkHandlerV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE,W) location: interface org.apache.commons.graph.visit.VisitAlgorithmsSelectorjava.lang.Object,java.lang.Object,org.apache.commons.graph.DirectedGraphV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE [ERROR] /srv/gump/public/workspace/commons-sandbox/graph/src/main/java/org/apache/commons/graph/flow/DefaultMaxFlowAlgorithmSelector.java:[82,47] cannot find symbol symbol : method applyingDepthFirstSearch(org.apache.commons.graph.flow.FlowNetworkHandlerV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE,W) location: interface org.apache.commons.graph.visit.VisitAlgorithmsSelectorjava.lang.Object,java.lang.Object,org.apache.commons.graph.DirectedGraphV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE [ERROR] /srv/gump/public/workspace/commons-sandbox/graph/src/main/java/org/apache/commons/graph/flow/DefaultMaxFlowAlgorithmSelector.java:[103,43] cannot find symbol symbol : method applyingBreadthFirstSearch(org.apache.commons.graph.flow.FlowNetworkHandlerV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE,W) location: interface org.apache.commons.graph.visit.VisitAlgorithmsSelectorjava.lang.Object,java.lang.Object,org.apache.commons.graph.DirectedGraphV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE [ERROR] /srv/gump/public/workspace/commons-sandbox/graph/src/main/java/org/apache/commons/graph/flow/DefaultMaxFlowAlgorithmSelector.java:[110,47] cannot find symbol symbol : method applyingBreadthFirstSearch(org.apache.commons.graph.flow.FlowNetworkHandlerV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE,W) location: interface org.apache.commons.graph.visit.VisitAlgorithmsSelectorjava.lang.Object,java.lang.Object,org.apache.commons.graph.DirectedGraphV,org.apache.commons.graph.flow.DefaultMaxFlowAlgorithmSelector.EdgeWrapperWE [ERROR] /srv/gump/public/workspace/commons-sandbox/graph/src/main/java/org/apache/commons/graph/spanning/DefaultSpanningTreeSourceSelector.java:[109,20] W,MwhereEdgesHaveWeights(M) in org.apache.commons.graph.shortestpath.PathWeightedEdgesBuilderjava.lang.Object,java.lang.Object cannot be applied to (org.apache.commons.graph.MapperWE,W) [ERROR] /srv/gump/public/workspace/commons-sandbox/graph/src/main/java/org/apache/commons/graph/connectivity/DefaultConnectivityAlgorithmsSelector.java:[69,64] cannot find symbol symbol
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 144 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: 12 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.198 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Fri May 11 04:26:15 UTC 2012 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
