[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 72 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: 27 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.313 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.071 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-sql (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-jelly-tags-sql has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 6 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-sql : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-jelly-tags-sql-11092012.jar] identifier set
to project name
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property
maven.jar.commons-jexl.
-DEBUG- (Apache Gump generated) Apache Maven Properties in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.xml
-DEBUG- Maven project properties in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.properties
-INFO- Project Reports in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports
-WARNING- No directory
[/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/gump_work/build_commons-jelly_commons-jelly-tags-sql.html
Work Name: build_commons-jelly_commons-jelly-tags-sql (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: maven --offline jar
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/sql]
-
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
You are working offline so the build will continue, but
commons-jelly-1.1-SNAPSHOT.jar may be out of date!
build:start:
java:prepare-filesystem:
[mkdir] Created dir:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
java:compile:
[echo] Compiling to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] Compiling 18 source files to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 1.5
[javac]
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/src/java/org/apache/commons/jelly/tags/sql/DataSourceWrapper.java:38:
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class DataSourceWrapper implements DataSource {
[javac]^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 1 warning
BUILD FAILED
File.. /home/gump/.maven/cache/maven-java-plugin-1.5/plugin.jelly
Element... ant:javac
Line.. 63
Column 48
Compile failed; see the compiler error output for details.
Total time: 7 seconds
Finished at: Tue Sep 11 07:15:15 UTC 2012
-
To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/atom.xml
== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1211092012, vmgump.apache.org:vmgump:1211092012
Gump E-mail Identifier (unique within run) #60.
--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About NullArgumentException
Hi Sébastien.
2012/9/11 Gilles Sadowski gil...@harfang.homelinux.org:
On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
Hi
What should I do there?
If we adopt the flexible policy (cf. other post), then you can do what you
want. ;-)
This is absolutely what I do not want to do... I've already realized
that I've been too flexible on e.g. formatting this last year...
The flexible policy wrt null checks is that we concile the possibility to
keep checking (for those who want to), and to not check. And from the user's
perspective, both can be handled in the same way (because it is a NPE[1]
that will be thrown, sooner or later). [From our perspective, CM will also
be consistent albeit, depending on our positions, sometimes incomplete. The
advantage of that policy is that, if we indeed want to fail as early as
possible, we can just incrementally add precondition checks without changing
the overall behaviour of the library: only the stack trace will become
shorter...]
Regards,
Gilles
[1] In CM 4.0, when we can change the inheritance tree for NAE.
Sébastien
I'm trying to work on MATH-854. It turns out that FieldElementT.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
Best,
Sébastien
/** {@inheritDoc} */
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
// SHOULD I CATCH NAE HERE?
Not _catch_ NAE but _throw_ it; the line in the loop would become:
final T entry = v.getEntry(i);
if (entry == null) {
throw new NullArgumentException(LocalizedFormats.INDEX, i);
}
out[i] = data[i].add(entry);
}
return new ArrayFieldVectorT(field, out, false);
}
}
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Is this good practice?
Hello. [...] I will try and do some benchmarking on this issue. I do not like these micro-optimizations which tend to be true optimizations with one version of the JVM, and are no longer with the next one. Also, while we are at it, is there a benefit in defining a separate, specialized method add(ArrayFieldVectorT). The other option would be to inline this method directly in the instanceof test in the general add(FieldVectorT). I guess the second solution would incur a slight overhead in those cases when the compiler can resolve the actual type of the parameter at compilation time. Even if the actual type can be inferred at compile time, Java will not call the method with the most specific argument type (IIRC): ArrayFieldVector a = new ArrayFieldVector(); ArrayFieldVector b = new ArrayFieldVector(); FieldVector c = b; FieldVector f = a.add(b); // Will call add(ArrayFieldVector). FieldVector g = a.add(c); // Will call add(FieldVector). I.e. what counts is the declared type. This was the reason for having several add methods: if the declared type is ArrayFieldVector, you gain one method call and/or you avoid the type check (instanceof). But I'm not sure the gain is worth the pain (again, the JIT seems to be pretty smart). If indeed the JIT compiler inlines everything (i.e. runtime analysis having shown which code path is actually run), then the nominal gain of one method call disappears (IIUC). If so, it would indeed be cleaner and more maintainable to remove the specific method (moving the specific code to the other one as you propose). [And it would also be more in accord with the best practice of programming by interfaces whereas, in Java, one had a strong incentive (performance) not to follow it. Maybe the contradiction doesn't exists anymore.] Best regards, Gilles The drawback of having two separate methods is that there is a little bit of maintenance work in order to ensure that both have the same contract (regarding, guess what, exceptions!). This is not a problem with the general version of the method, which is specified in an interface/abstract class. This is more problematic with the specific version of the method. Of course, this only requires to be careful, it's not so much of a hassle. Any thoughts on this? Sébastien Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Commons Codec 1.7-RC2
Hello All: This is a VOTE to release Commons Codec 1.7-RC2. The differences with RC1 are: - Added missing ASF header to Sha2CryptTest.java - Fixed failing tests on IBM JVM and removed related release notes documentation. - Changes in changes.xml. - Added JRE requirement to release notes. Commons Codec 1.7 requires a minimum of Java 1.6 Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. This VOTE is open for at least 72 hours until September 14 2012 at 9:30 AM EST. The files: https://repository.apache.org/content/repositories/orgapachecommons-051/ The tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC2 The site: https://people.apache.org/builds/commons/commons-codec/1.7/RC2/ Note that the JIRA report is empty and it is a known issue in the Maven JIRA plugin and that requires a new plugin version. Thank you, Gary Gregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory http://twitter.com/GaryGregory
Re: [Math] About NullArgumentException
On Tue, Sep 11, 2012 at 07:46:20AM +0200, Sébastien Brisard wrote: Hello, 2012/9/11 Gilles Sadowski gil...@harfang.homelinux.org: On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote: On 9/10/12 11:47 AM, Sébastien Brisard wrote: Hi What should I do there? I'm trying to work on MATH-854. It turns out that FieldElementT.add throws a NAE. Should I catch it below, and rethrow it with a more detailed message (including the entry index)? IMO, yes. I would also check v itself and add to the javadoc contract that IAE is thrown if v is null. This is not consistently done in [math], though, and rarely in the linear package, so I am OK just letting the NPE propagate if v is null. It is a little awkward that v itself being null leads to NPE, but a component of it null leads to MIAE. Awkward? Of course it is; that's what I explained two posts ago. If we want to allow for the possibility of checking for null (and I agree that it could be useful to pinpoint the problem by passing the information about which index contains an invalid null entry), then we should adopt the second option which I presented in that preceding post: NullArgumentException inherits from NullPointerException This really solves all issues (now that Luc has said that it is not a problem if this one exception escapes the single-root hierarchy): It allows to check for null in CM code and raise the same kind of exception that would arise when no null check is performed. Both flexible and consistent. I may be a bit slow, but I understood that localized error messages were an absolute requirement on Luc's side (which, BTW is good to know, I have always been wondering why we cared so much about localized error messages...). As I've already expressed in the past, I think that localization (as required by some of Luc's applications), as well as the more recent example of passing null to some constructors (as provided by Phil) are indeed to be considered as _outside_ the realm of CM: They are application requirements, pushed down to CM, that cannot be given a self-consistent rationale. When adding a feature to a library like CM, I think that it is very important (namely for long-term maintenance) that it does not rely on out-of-band information. I mean that the Why does this feature exist? should not need references to external-only requirements to be understandable. Of course, by external-only I mean that the feature's implementation could be changed just because the applications that use it changes. E.g. if the TranslatorService, which I imagined in a previous post, existed, Luc's application could use it to fulfill its Error messages should be displayed in French requirement, and the localization of CM error messages could be removed from CM, without CM loosing anything. In that sense, the support of localization is not on the same footing as the support of some math algorithm because the latter is within the core business of CM, while the former is not. IMHO, the more a codebase grows, the less it should contain internal inconsistencies. Of course, we can conclude that now is not the right moment to clean up this or other defects of CM (e.g. because nobody has the time to do it, or to please people who have come to rely on the current state of affairs) but that is not making the issue go away. So, if I understand correctly, NAE inheriting from NPE would mean no error message. No. In the present case, if we can't specify the index of the faulty entry in the error message, You can: throw new NullArgumentException(LocalizedFormats.INDEX, i); I don't see the benefit of NAE over NPE. I must have missed something; I guess that NAE would inherit from NPE, AND implement ExceptionContextProvider, is that right? In that case, I like this solution. Exactly. The _sole_ difference with the current NAE will be the change in the extends clause, from public class NullArgumentException extends MathIllegalArgumentException to public class NullArgumentException extends NullPointerException implements ExceptionContextProvider [And the throw statement above will be the same before and after this change.] Sorry for polluting this thread with silly questions, but I am not used to writing programs for third-party end-users (I *AM* the end-user, or maybe my student enxt door), so I have to say I'm not familiar with the concerns raised in this thread. They are not silly questions. It's precisely my point that such questions will arise (because of CM is lacking self-consistency). I'm pretty sure that none of us is familiar with being only on one side of the border; we all are also _users_ of CM and, quite often, the user's point-of-view is given the priority even if it leads to decisions that are sub-optimal in the longer term. Best regards, Gilles - To unsubscribe, e-mail:
[continuum] BUILD FAILURE: Apache Commons - Commons CSV -
Group (shared) Maven 2 Build Definition (Java 1.5) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 68 X-Continuum-Project-Name: Commons CSV Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=24781projectId=68 Build statistics: State: Failed Previous State: Ok Started at: Tue 11 Sep 2012 18:20:10 + Finished at: Tue 11 Sep 2012 18:21:12 + Total time: 1m 2s Build Trigger: Schedule Build Number: 116 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.32-41-server arch: amd64 Family: unix SCM Changes: Changed: ggregory @ Tue 11 Sep 2012 18:18:14 + Comment: Fix compilation issue. Files changed: /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/perf ( 1383504 ) /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/perf/PerformanceTest.java ( 1383504 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Group (shared) Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 69 Failures: 0 Errors: 0 Success Rate: 100 Total time: 1.656 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Plan for 2.0
sebb wrote: On 10 September 2012 20:33, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 09.09.2012 14:26, schrieb sebb: On 8 September 2012 15:45, Oliver Heger oliver.he...@oliver-heger.de wrote: [snip] Some classes of [lang] are exposed in the public API of [configuration]. For instance, variable substitution in configuration files is done by a org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to use can be set. So switching to [lang3] will effectively change the public API of [configuration] in an incompatible way. That seems very fragile. There has to be a better way to handle that. Fixing it will break the API (once), but at least the API will then be stable, regardless of what happens with LANG. Do you mean all interfaces or classes from 3rd party libraries should be wrapped so that they do not leak in the public API? Not sure it's necessary to wrap all 3rd party library APIs, just don't expose their classes in the Configuration API. I agree that using 3rd party classes in the public API is obviously fragile and should be avoided as much as possible. But I am not sure whether a radical wrapping approach works in all cases. Also, it might make reuse of classes harder for client code. Take for instance the StrSubstitutor example. A client may already have a custom implementation to be used with the corresponding [lang] classes. Now this implementation cannot be used together with [configuration] because here a slightly different interface is required - although the functionality is the same. If you update Configuration to use lang3, then the custom implementation will break anyway - unless Configuration is updated to work with both Lang and Lang3. Is not possible here. The Configuration interface throws a checked exception which is derived from one of lang. And because of this you need currently lang as compile dep - runtime is not enough :-/ Do you really want that? Does not seem scalable. At least we can now think about it to avoid such a situation in future. ConfigurationException in configuration-3 should derive now directly from Exception. If custom classes in future have to implement a Configuration interface, rather than something from Lang, then at least the custom class is then only dependent on the Config. API. Whatever happens, custom classes are going to need to be changed if support for Lang is dropped in favour of Lang3. Or am I missing something here? Not sure how to deal with this issue in general. Once the API dependency on Lang is removed, it won't be an issue. We can always add a convenience wrapper for the current lang version, e.g. if we use in future an interfaces like org.apache.commons.confiugration.text.Substitutor our implementation can still depend on lang3 code. We may even provide a wrapper class as convenience for custom implementations of the lang3 StrSubstitutor. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Plan for 2.0
On 11 September 2012 19:22, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: On 10 September 2012 20:33, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 09.09.2012 14:26, schrieb sebb: On 8 September 2012 15:45, Oliver Heger oliver.he...@oliver-heger.de wrote: [snip] Some classes of [lang] are exposed in the public API of [configuration]. For instance, variable substitution in configuration files is done by a org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to use can be set. So switching to [lang3] will effectively change the public API of [configuration] in an incompatible way. That seems very fragile. There has to be a better way to handle that. Fixing it will break the API (once), but at least the API will then be stable, regardless of what happens with LANG. Do you mean all interfaces or classes from 3rd party libraries should be wrapped so that they do not leak in the public API? Not sure it's necessary to wrap all 3rd party library APIs, just don't expose their classes in the Configuration API. I agree that using 3rd party classes in the public API is obviously fragile and should be avoided as much as possible. But I am not sure whether a radical wrapping approach works in all cases. Also, it might make reuse of classes harder for client code. Take for instance the StrSubstitutor example. A client may already have a custom implementation to be used with the corresponding [lang] classes. Now this implementation cannot be used together with [configuration] because here a slightly different interface is required - although the functionality is the same. If you update Configuration to use lang3, then the custom implementation will break anyway - unless Configuration is updated to work with both Lang and Lang3. Is not possible here. The Configuration interface throws a checked exception which is derived from one of lang. And because of this you need currently lang as compile dep - runtime is not enough :-/ Another unfortunate API dependency ... Do you really want that? Does not seem scalable. At least we can now think about it to avoid such a situation in future. ConfigurationException in configuration-3 should derive now directly from Exception. If custom classes in future have to implement a Configuration interface, rather than something from Lang, then at least the custom class is then only dependent on the Config. API. Whatever happens, custom classes are going to need to be changed if support for Lang is dropped in favour of Lang3. Or am I missing something here? Not sure how to deal with this issue in general. Once the API dependency on Lang is removed, it won't be an issue. We can always add a convenience wrapper for the current lang version, e.g. if we use in future an interfaces like org.apache.commons.confiugration.text.Substitutor our implementation can still depend on lang3 code. We may even provide a wrapper class as convenience for custom implementations of the lang3 StrSubstitutor. [Existing custom implementations are likely to target lang2 rather than lang3, surely?] Configuration developers need to decide whether to maintain compatibility or break it. If the former, all talk of switching to Lang3 is irrelevant, as it cannot be done cleanly. The best one could do would be to use Lang3 internally, but still use lang2 for external APIs. Rather messy just to use lang3. If the latter, then make sure that the API is changed such that it depends only on code which is in Configuration. Otherwise this issue will recur. For obvious reasons, all breaking changes should be done in the same release if at all possible. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-jelly-tags-sql (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-jelly-tags-sql has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-sql : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-jelly-tags-sql-11092012.jar] identifier set
to project name
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property
maven.jar.commons-jexl.
-DEBUG- (Apache Gump generated) Apache Maven Properties in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.xml
-DEBUG- Maven project properties in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.properties
-INFO- Project Reports in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports
-WARNING- No directory
[/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/gump_work/build_commons-jelly_commons-jelly-tags-sql.html
Work Name: build_commons-jelly_commons-jelly-tags-sql (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: maven --offline jar
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/sql]
-
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
You are working offline so the build will continue, but
commons-jelly-1.1-SNAPSHOT.jar may be out of date!
build:start:
java:prepare-filesystem:
[mkdir] Created dir:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
java:compile:
[echo] Compiling to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] Compiling 18 source files to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 1.5
[javac]
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/src/java/org/apache/commons/jelly/tags/sql/DataSourceWrapper.java:38:
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class DataSourceWrapper implements DataSource {
[javac]^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 1 warning
BUILD FAILED
File.. /home/gump/.maven/cache/maven-java-plugin-1.5/plugin.jelly
Element... ant:javac
Line.. 63
Column 48
Compile failed; see the compiler error output for details.
Total time: 6 seconds
Finished at: Tue Sep 11 19:17:31 UTC 2012
-
To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/atom.xml
== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 06001211092012, vmgump.apache.org:vmgump:06001211092012
Gump E-mail Identifier (unique within run) #13.
--
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
[continuum] BUILD FAILURE: Apache Commons - Commons CSV -
Group (shared) Maven 2 Build Definition (Java 1.5) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 68 X-Continuum-Project-Name: Commons CSV Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=24782projectId=68 Build statistics: State: Failed Previous State: Failed Started at: Tue 11 Sep 2012 19:20:13 + Finished at: Tue 11 Sep 2012 19:21:12 + Total time: 58s Build Trigger: Schedule Build Number: 116 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.32-41-server arch: amd64 Family: unix SCM Changes: Changed: ggregory @ Tue 11 Sep 2012 18:29:53 + Comment: Use commons-parent 26. Files changed: /commons/proper/csv/trunk/pom.xml ( 1383513 ) Changed: ggregory @ Tue 11 Sep 2012 18:30:53 + Comment: Define groupId org.apache.commons Files changed: /commons/proper/csv/trunk/pom.xml ( 1383514 ) Changed: ggregory @ Tue 11 Sep 2012 18:51:54 + Comment: Add more reports. Files changed: /commons/proper/csv/trunk/LICENSE-header.txt ( 1383535 ) /commons/proper/csv/trunk/checkstyle.xml ( 1383535 ) /commons/proper/csv/trunk/pom.xml ( 1383535 ) Changed: ggregory @ Tue 11 Sep 2012 18:54:17 + Comment: Add missing ASF header. Files changed: /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/perf/PerformanceTest.java ( 1383545 ) Changed: ggregory @ Tue 11 Sep 2012 18:55:18 + Comment: Add missing ASF header and XML PI. Files changed: /commons/proper/csv/trunk/pom.xml ( 1383553 ) Changed: ggregory @ Tue 11 Sep 2012 18:55:58 + Comment: Add missing ASF header. Files changed: /commons/proper/csv/trunk/src/site/site.xml ( 1383554 ) Changed: ggregory @ Tue 11 Sep 2012 18:58:30 + Comment: Better version and date. Files changed: /commons/proper/csv/trunk/src/changes/changes.xml ( 1383555 ) Changed: ggregory @ Tue 11 Sep 2012 19:03:03 + Comment: Add default serialVersionUID to two classes. Files changed: /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java ( 1383556 ) /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java ( 1383556 ) Changed: ggregory @ Tue 11 Sep 2012 19:03:45 + Comment: Remove unneeded @SuppressWarnings(unused) Files changed: /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFileParserTest.java ( 1383557 ) Changed: ggregory @ Tue 11 Sep 2012 19:08:56 + Comment: Fix incorrect Javadoc method reference. Files changed: /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/ExtendedBufferedReader.java ( 1383558 ) Changed: ggregory @ Tue 11 Sep 2012 19:17:25 + Comment: Refactor '\r' and '\n' into constants. Files changed: /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/ExtendedBufferedReader.java ( 1383564 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Group (shared) Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 69 Failures: 0 Errors: 0 Success Rate: 100 Total time: 1.3530002 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Plan for 2.0
Am 11.09.2012 00:08, schrieb sebb: On 10 September 2012 20:33, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 09.09.2012 14:26, schrieb sebb: On 8 September 2012 15:45, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 08.09.2012 03:44, schrieb sebb: On 7 September 2012 20:46, Oliver Heger oliver.he...@oliver-heger.de wrote: Hi all, the pom was updated to make 2.0-SNAPSHOT the current development version. This means we are free to implement major changes without having to enforce binary backwards compatibility. BC breakage will require package and Maven coordinate changes at some point just before release. Yes, I am aware of this. The question is: What are the goals for version 2.0? I would recommend to define a clear focus so that the next release will not take too long. Obviously there are already people waiting for a [configuration] version compatible with [lang3]. Some points I have in mind are the following ones: - Switch to [lang3]. This is the main reason for going to version 2.0 because this cannot be done in a binary compatible way. Not sure I follow that. Why would changing a dependency affect the API for Configuration? Does not make sense to me. Some classes of [lang] are exposed in the public API of [configuration]. For instance, variable substitution in configuration files is done by a org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to use can be set. So switching to [lang3] will effectively change the public API of [configuration] in an incompatible way. That seems very fragile. There has to be a better way to handle that. Fixing it will break the API (once), but at least the API will then be stable, regardless of what happens with LANG. Do you mean all interfaces or classes from 3rd party libraries should be wrapped so that they do not leak in the public API? Not sure it's necessary to wrap all 3rd party library APIs, just don't expose their classes in the Configuration API. I agree that using 3rd party classes in the public API is obviously fragile and should be avoided as much as possible. But I am not sure whether a radical wrapping approach works in all cases. Also, it might make reuse of classes harder for client code. Take for instance the StrSubstitutor example. A client may already have a custom implementation to be used with the corresponding [lang] classes. Now this implementation cannot be used together with [configuration] because here a slightly different interface is required - although the functionality is the same. If you update Configuration to use lang3, then the custom implementation will break anyway - unless Configuration is updated to work with both Lang and Lang3. Do you really want that? Does not seem scalable. If custom classes in future have to implement a Configuration interface, rather than something from Lang, then at least the custom class is then only dependent on the Config. API. Whatever happens, custom classes are going to need to be changed if support for Lang is dropped in favour of Lang3. Or am I missing something here? Yes, sure, client code will be affected by this change. Not sure how to deal with this issue in general. Once the API dependency on Lang is removed, it won't be an issue. My point was if we use functionality from a library like [lang] to implement concepts in [configuration], it might be natural to somehow pass objects from this library to [configuration] objects. Then they become part of the public API of [configuration]. Avoiding this will take some effort and may be less straight-forward from a user's point of view. Oliver Oliver - 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: [VOTE] Release Commons Codec 1.7-RC2
+1 The open points from the previous RC have been addressed. BTW: The success rate of only 99.422% in the surefire report seems to be caused by the fact that two tests in QuotedPrintableCodecTest are skipped. Of course not an issue. Oliver Am 11.09.2012 14:26, schrieb Gary Gregory: Hello All: This is a VOTE to release Commons Codec 1.7-RC2. The differences with RC1 are: - Added missing ASF header to Sha2CryptTest.java - Fixed failing tests on IBM JVM and removed related release notes documentation. - Changes in changes.xml. - Added JRE requirement to release notes. Commons Codec 1.7 requires a minimum of Java 1.6 Changes in this version include: New features: o CODEC-157: DigestUtils: Add MD2 APIs. Thanks to ggregory. o CODEC-156: DigestUtils: add APIs named after standard algorithm name SHA-1. Thanks to ggregory. o CODEC-155: DigestUtils.getDigest(String) should throw IllegalArgumentException instead of RuntimeException. Thanks to ggregory. o CODEC-153: Create a class MessageDigestAlgorithms to define standard algorithm names. Thanks to ggregory. o CODEC-152: DigestUtils.getDigest(String) loses the original exception. Thanks to ggregory. o CODEC-151: Remove unnecessary attempt to fill up the salt variable in UnixCrypt. Thanks to lathspell. o CODEC-150: Remove unnecessary call to Math.abs(). Thanks to lathspell. o CODEC-148: More tests and minor things. Thanks to lathspell. o CODEC-146: Added regression tests for PhoneticEngine based on Solr-3.6.0. Thanks to Julius Davies. o CODEC-139: DigestUtils: add updateDigest methods and make methods public. Thanks to dsebastien. o CODEC-133: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. Thanks to lathspell. o CODEC-130: Base64InputStream.skip skips underlying stream, not output. Thanks to tn. o CODEC-63: Implement NYSIIS phonetic encoder. Thanks to bayard. Fixed Bugs: o CODEC-96: Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder. Note: the fix breaks binary compatibility, however the changes are to a class (BaseNCodec) which is intended for internal use. Thanks to sebb. o CODEC-138: Complete FilterInputStream interface for BaseNCodecInputStream. o CODEC-136: Use Charset objects when possible, create Charsets for required character encodings. o CODEC-132: BeiderMorseEncoder OOM issues. Thanks to rcmuir. o CODEC-131: DoubleMetaphone javadoc contains dead links. Thanks to smolav. Changes: o CODEC-147: BeiderMorseEncoder/PhoneticEngine: make results deterministic by using a LinkedHashSet instead of a HashSet. o CODEC-143: StringBuffer could be replaced by StringBuilder for local variables. This VOTE is open for at least 72 hours until September 14 2012 at 9:30 AM EST. The files: https://repository.apache.org/content/repositories/orgapachecommons-051/ The tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC2 The site: https://people.apache.org/builds/commons/commons-codec/1.7/RC2/ Note that the JIRA report is empty and it is a known issue in the Maven JIRA plugin and that requires a new plugin version. Thank you, Gary Gregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Plan for 2.0
On 11 September 2012 20:27, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 11.09.2012 00:08, schrieb sebb: On 10 September 2012 20:33, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 09.09.2012 14:26, schrieb sebb: On 8 September 2012 15:45, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 08.09.2012 03:44, schrieb sebb: On 7 September 2012 20:46, Oliver Heger oliver.he...@oliver-heger.de wrote: Hi all, the pom was updated to make 2.0-SNAPSHOT the current development version. This means we are free to implement major changes without having to enforce binary backwards compatibility. BC breakage will require package and Maven coordinate changes at some point just before release. Yes, I am aware of this. The question is: What are the goals for version 2.0? I would recommend to define a clear focus so that the next release will not take too long. Obviously there are already people waiting for a [configuration] version compatible with [lang3]. Some points I have in mind are the following ones: - Switch to [lang3]. This is the main reason for going to version 2.0 because this cannot be done in a binary compatible way. Not sure I follow that. Why would changing a dependency affect the API for Configuration? Does not make sense to me. Some classes of [lang] are exposed in the public API of [configuration]. For instance, variable substitution in configuration files is done by a org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to use can be set. So switching to [lang3] will effectively change the public API of [configuration] in an incompatible way. That seems very fragile. There has to be a better way to handle that. Fixing it will break the API (once), but at least the API will then be stable, regardless of what happens with LANG. Do you mean all interfaces or classes from 3rd party libraries should be wrapped so that they do not leak in the public API? Not sure it's necessary to wrap all 3rd party library APIs, just don't expose their classes in the Configuration API. I agree that using 3rd party classes in the public API is obviously fragile and should be avoided as much as possible. But I am not sure whether a radical wrapping approach works in all cases. Also, it might make reuse of classes harder for client code. Take for instance the StrSubstitutor example. A client may already have a custom implementation to be used with the corresponding [lang] classes. Now this implementation cannot be used together with [configuration] because here a slightly different interface is required - although the functionality is the same. If you update Configuration to use lang3, then the custom implementation will break anyway - unless Configuration is updated to work with both Lang and Lang3. Do you really want that? Does not seem scalable. If custom classes in future have to implement a Configuration interface, rather than something from Lang, then at least the custom class is then only dependent on the Config. API. Whatever happens, custom classes are going to need to be changed if support for Lang is dropped in favour of Lang3. Or am I missing something here? Yes, sure, client code will be affected by this change. Not sure how to deal with this issue in general. Once the API dependency on Lang is removed, it won't be an issue. My point was if we use functionality from a library like [lang] to implement concepts in [configuration], it might be natural to somehow pass objects from this library to [configuration] objects. Then they become part of the public API of [configuration]. Avoiding this will take some effort Yes, but that is worthwhile if it reduces the end-user workload either now or in future maintenence. Maybe it would be possible to use a service provider interface style configuration? and may be less straight-forward from a user's point of view. Binding the Configuration API to the Lang API means that updating to Lang3 forces source changes on users. That's not ideal either - in fact it's worse, as as it's potentially an ongoing issue. Oliver Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-dbcp has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 69 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-12092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-12092012.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
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 69 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-12092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-12092012.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-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. 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.001 sec Running org.apache.commons.exec.util.MapUtilTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.exec.DefaultExecutorTest FOO.. gdal_translate HDF5:/home/kk/grass/data/4404.he5://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. 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.020 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.027 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.027 ms Process completed in 2005 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2002 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls 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 8046 millis; above is its output Processes terminated: 6 killed: 0 Multiplier: 1 MaxRetries: 180 Elapsed (avg ms): 1004 Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.73 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: Wed Sep 12 02:06:28 UTC 2012 [INFO] Final Memory: 28M/67M [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 1212092012, vmgump.apache.org:vmgump:1212092012 Gump E-mail Identifier (unique within run) #18. -- 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 74 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: 58 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: 1347422177429
[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:
Re: [Math] About NullArgumentException
Hi Phil,
2012/9/10 Phil Steitz phil.ste...@gmail.com:
On 9/10/12 11:47 AM, Sébastien Brisard wrote:
Hi
What should I do there?
I'm trying to work on MATH-854. It turns out that FieldElementT.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
IMO, yes.
I would also check v itself and add to the javadoc contract that IAE
is thrown if v is null. This is not consistently done in [math],
though, and rarely in the linear package, so I am OK just letting
the NPE propagate if v is null. It is a little awkward that v
itself being null leads to NPE, but a component of it null leads to
MIAE.
I agree with you, it feels weird. I found a better way: we need to
make sure that entries of FieldVector can *never* be null. This means
checking for null in setters, constructors and the likes. What do you
think?
Sébastien
Phil
Best,
Sébastien
/** {@inheritDoc} */
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
// SHOULD I CATCH NAE HERE?
}
return new ArrayFieldVectorT(field, out, false);
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-chain2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 91 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: 60 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: 58 seconds [INFO] Finished at: Wed Sep 12 05:08:10 UTC 2012 [INFO] Final Memory: 113M/241M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml - Atom:
[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 74 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: 16 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.015 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 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.004 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.309 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 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: 15 seconds [INFO] Finished at: Wed Sep 12 05:23:48 UTC 2012 [INFO] Final Memory: 25M/61M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 69 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils : Commons DbUtils
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to
project name
-INFO- Optional dependency mockito failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
-WARNING- No directory
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
Downloading:
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.pom
1K downloaded (mockito-core-1.9.0.pom)
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded (hamcrest-all-1.1.pom)
Downloading:
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded (hamcrest-all-1.1.jar)
1381K downloaded (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
main:
[copy] Copying 2 files to
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1347427771787
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 28 source files to
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
