[monitoring] Java version
I'm looking at the [monitoring] sandbox component. (Notwithstanding some complex approach) it can't be built with a JDK 1.5 due to the interface additions made to JDBC in Java 1.6. As 1.5 is EOL and this is a sandbox component that may well never see the light of day anyway, any objections to upgrading to 1.6 and adding the missing methods to the JDBC implementations so we can at least built the thing simply? Matt
[compress] ZipFile and Duplicate Entries
Hi, over in Ant land a bug was raised that points at a problem in ZipFile (Commons Compress' zip package is a fork of Ant's code and I try to keep them in sync). When an archive contains duplicate entries - which is totally valid in ZIPs - ZipFile's getEntry can sometimes return ZipArchiveEntry instances that will receive null for ZipFile's getInputStream. This is COMPRESS-227 which contains the details of the problem. I've for now fixed it in trunk by ignoring all but the last entry od the same name seen while parsing the central directory. I've chosen to pick the last since this is what ZipFile used to do for duplicate entries without extra fields anyway. There may be reasons to return only the first entry and there may even be reasons to provide a different method that returned all entries of a given name, something like ListZipArchiveEntry getEntries(String name) The later would require some more book-keeping but I don't think the performance impact would be too big. Tools like InfoZIP's zip/unzip list all entries of a given name. Do you think it is worth it? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [monitoring] Java version
Hrm, actually I misspoke. I was thinking of the breaking JDBC changes in Java 7. Same difference except I'm not willing to push [monitoring] that far yet. Disregard and I'm building with Java 6 :P Matt On Mon, May 20, 2013 at 10:06 AM, Matt Benson gudnabr...@gmail.com wrote: I'm looking at the [monitoring] sandbox component. (Notwithstanding some complex approach) it can't be built with a JDK 1.5 due to the interface additions made to JDBC in Java 1.6. As 1.5 is EOL and this is a sandbox component that may well never see the light of day anyway, any objections to upgrading to 1.6 and adding the missing methods to the JDBC implementations so we can at least built the thing simply? Matt
[VOTE][RESULT] Release of Commons Logging 1.1.3 based on RC2
On 05/16/2013 10:28 PM, Thomas Neidhart wrote: Hi, I'd like to call a vote for releasing Commons Logging 1.1.3 based on RC2. This release candidate has the following changes compared to RC1: * fix ant build script: version, dependencies, created artifacts The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-006/commons-logging/commons-logging/1.1.3/ Distribution files: https://dist.apache.org/repos/dist/dev/commons/logging/ The tag: https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_3_RC2/ The site: http://people.apache.org/builds/commons/logging/1.1.3/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-logging-1.1.3 artifacts and vote! [ ] +1 release it. [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... Vote will remain open for at least 72 hours. The vote to release Commons-Logging 1.1.3 has passed with the following votes: +1 Emmanuel Bourg (PMC) +1 Oliver Heger (PMC) +1 Gary Gregory (PMC) +1 Roger Whitcomb (non-binding) +1 myself (PMC) Thanks for checking the release and voting! Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [monitoring] Java version
Hi you can still add the methods without @Override, it will make it happy for both jvm. That said using proxies is another solution which works better in general for such cases IMO. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/5/20 Matt Benson gudnabr...@gmail.com Hrm, actually I misspoke. I was thinking of the breaking JDBC changes in Java 7. Same difference except I'm not willing to push [monitoring] that far yet. Disregard and I'm building with Java 6 :P Matt On Mon, May 20, 2013 at 10:06 AM, Matt Benson gudnabr...@gmail.com wrote: I'm looking at the [monitoring] sandbox component. (Notwithstanding some complex approach) it can't be built with a JDK 1.5 due to the interface additions made to JDBC in Java 1.6. As 1.5 is EOL and this is a sandbox component that may well never see the light of day anyway, any objections to upgrading to 1.6 and adding the missing methods to the JDBC implementations so we can at least built the thing simply? Matt
Re: [monitoring] Java version
Both good points, Romain! If anyone decides to mess with [monitoring] in the future hopefully they'll be remembered. Matt On Mon, May 20, 2013 at 11:38 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi you can still add the methods without @Override, it will make it happy for both jvm. That said using proxies is another solution which works better in general for such cases IMO. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/5/20 Matt Benson gudnabr...@gmail.com Hrm, actually I misspoke. I was thinking of the breaking JDBC changes in Java 7. Same difference except I'm not willing to push [monitoring] that far yet. Disregard and I'm building with Java 6 :P Matt On Mon, May 20, 2013 at 10:06 AM, Matt Benson gudnabr...@gmail.com wrote: I'm looking at the [monitoring] sandbox component. (Notwithstanding some complex approach) it can't be built with a JDK 1.5 due to the interface additions made to JDBC in Java 1.6. As 1.5 is EOL and this is a sandbox component that may well never see the light of day anyway, any objections to upgrading to 1.6 and adding the missing methods to the JDBC implementations so we can at least built the thing simply? Matt
Re: [compress] ZipFile and Duplicate Entries
On 20 May 2013 16:48, Stefan Bodewig bode...@apache.org wrote: Hi, over in Ant land a bug was raised that points at a problem in ZipFile (Commons Compress' zip package is a fork of Ant's code and I try to keep them in sync). When an archive contains duplicate entries - which is totally valid in ZIPs - ZipFile's getEntry can sometimes return ZipArchiveEntry instances that will receive null for ZipFile's getInputStream. This is COMPRESS-227 which contains the details of the problem. I've for now fixed it in trunk by ignoring all but the last entry od the same name seen while parsing the central directory. I've chosen to pick the last since this is what ZipFile used to do for duplicate entries without extra fields anyway. There may be reasons to return only the first entry and there may even be reasons to provide a different method that returned all entries of a given name, something like ListZipArchiveEntry getEntries(String name) The later would require some more book-keeping but I don't think the performance impact would be too big. Tools like InfoZIP's zip/unzip list all entries of a given name. Do you think it is worth it? What do WinZip and Windows do? Are there any sample Zips with multiple entries? Stefan - 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
Creating CSVFormats (again :)
Hi guys,
a while back we had this discussion [1] about the current state of the
CSVFormat API. We were still not completely happy with it and Oliver came
up with a new suggestion [2].
This weekend I finally had some time to hack something together. I've
created a mirror of CSV rev. 1484347 at github [3].
This proposal uses CSVFormatModifier objects to change a CSVFormat. The API
relies on static imports of factory methods for CSVFormatModifiers and
looks like the following:
CSVFormat modifed = CSVFormat.DEFAULT.with(
delimiter(';'),
noEscape(),
commentStart('#'));
So far I've implemented methods for changing delimiter, commentStart,
escape and quote policy (have a look at CSVFormatModifierTest). The
approach has the advantage of being short like the initial implementation,
while making sure that CSVFormat is immutable and validated at construction
time. The draw back however is, that it is a bit of a pain to get all the
static imports in place (at least this is my feeling with Eclipse, any
suggestions on how to work efficiently with static imports in eclipse are
appreciated :)
Now I'd like to ask you for feedback. Do you like this approach? Any
suggestions?
One thing I'm not sure about is MutableCSVFormat. Maybe this can be merged
together with CSVFormatModifier.
Regards,
Benedikt
[1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
[2] http://markmail.org/message/vjjdbckwr4dlqp2b
[3] https://github.com/britter/apache-commons-csv-mirror
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
[CSV] Creating CSVFormats (again :)
Sorry, forgot the prefix...
2013/5/20 Benedikt Ritter brit...@apache.org
Hi guys,
a while back we had this discussion [1] about the current state of the
CSVFormat API. We were still not completely happy with it and Oliver came
up with a new suggestion [2].
This weekend I finally had some time to hack something together. I've
created a mirror of CSV rev. 1484347 at github [3].
This proposal uses CSVFormatModifier objects to change a CSVFormat. The
API relies on static imports of factory methods for CSVFormatModifiers and
looks like the following:
CSVFormat modifed = CSVFormat.DEFAULT.with(
delimiter(';'),
noEscape(),
commentStart('#'));
So far I've implemented methods for changing delimiter, commentStart,
escape and quote policy (have a look at CSVFormatModifierTest). The
approach has the advantage of being short like the initial implementation,
while making sure that CSVFormat is immutable and validated at
construction time. The draw back however is, that it is a bit of a pain to
get all the static imports in place (at least this is my feeling with
Eclipse, any suggestions on how to work efficiently with static imports in
eclipse are appreciated :)
Now I'd like to ask you for feedback. Do you like this approach? Any
suggestions?
One thing I'm not sure about is MutableCSVFormat. Maybe this can be merged
together with CSVFormatModifier.
Regards,
Benedikt
[1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
[2] http://markmail.org/message/vjjdbckwr4dlqp2b
[3] https://github.com/britter/apache-commons-csv-mirror
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: Creating CSVFormats (again :)
Hi
A real inline builder (withDelimiter(...)...) is better to get completion
and linear reading of the code IMO
Static imports are not fine for everbody from my experience
Le 20 mai 2013 22:05, Benedikt Ritter brit...@apache.org a écrit :
Hi guys,
a while back we had this discussion [1] about the current state of the
CSVFormat API. We were still not completely happy with it and Oliver came
up with a new suggestion [2].
This weekend I finally had some time to hack something together. I've
created a mirror of CSV rev. 1484347 at github [3].
This proposal uses CSVFormatModifier objects to change a CSVFormat. The API
relies on static imports of factory methods for CSVFormatModifiers and
looks like the following:
CSVFormat modifed = CSVFormat.DEFAULT.with(
delimiter(';'),
noEscape(),
commentStart('#'));
So far I've implemented methods for changing delimiter, commentStart,
escape and quote policy (have a look at CSVFormatModifierTest). The
approach has the advantage of being short like the initial implementation,
while making sure that CSVFormat is immutable and validated at construction
time. The draw back however is, that it is a bit of a pain to get all the
static imports in place (at least this is my feeling with Eclipse, any
suggestions on how to work efficiently with static imports in eclipse are
appreciated :)
Now I'd like to ask you for feedback. Do you like this approach? Any
suggestions?
One thing I'm not sure about is MutableCSVFormat. Maybe this can be merged
together with CSVFormatModifier.
Regards,
Benedikt
[1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
[2] http://markmail.org/message/vjjdbckwr4dlqp2b
[3] https://github.com/britter/apache-commons-csv-mirror
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
[parent][io] v29 and jacoco
Hi All: I updated my local POM for [io] to commons-parent 29 and ran mvn site. The Jacoco report shows FileUtils at 0% which makes no sense since we have a FileUtilsTestCase class. Can anyone reproduce this? Thank you, Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [parent][io] v29 and jacoco
Gary Gregory garydgreg...@gmail.com a écrit : Hi All: I updated my local POM for [io] to commons-parent 29 and ran mvn site. The Jacoco report shows FileUtils at 0% which makes no sense since we have a FileUtilsTestCase class. Can anyone reproduce this? I'm not in front of my computer right now. Do the tests end up with expected exceptions using the junit4 annotation @Test(expected=SomeException.class) I think such expected failures are not handled properly yet by Jacoco. Luc Thank you, Gary -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Creating CSVFormats (again :)
Le 20/05/2013 22:07, Romain Manni-Bucau a écrit : A real inline builder (withDelimiter(...)...) is better to get completion and linear reading of the code IMO +1 Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: Creating CSVFormats (again :)
On 20 May 2013 21:07, Romain Manni-Bucau rmannibu...@gmail.com wrote:
Hi
A real inline builder (withDelimiter(...)...) is better to get completion
and linear reading of the code IMO
What do you mean exactly by a real builder?
Please show the exact syntax.
Static imports are not fine for everbody from my experience
Nothing is going to be fine for everybody.
But static imports seem to work quite well for JUnit4.
Le 20 mai 2013 22:05, Benedikt Ritter brit...@apache.org a écrit :
Hi guys,
a while back we had this discussion [1] about the current state of the
CSVFormat API. We were still not completely happy with it and Oliver came
up with a new suggestion [2].
This weekend I finally had some time to hack something together. I've
created a mirror of CSV rev. 1484347 at github [3].
This proposal uses CSVFormatModifier objects to change a CSVFormat. The API
relies on static imports of factory methods for CSVFormatModifiers and
looks like the following:
CSVFormat modifed = CSVFormat.DEFAULT.with(
I don't like the DEFAULT; seems to me it could be dropped.
delimiter(';'),
noEscape(),
commentStart('#'));
Also, I think one could chain the method parameters like so:
CSVFormat modifed =
CSVFormat.using(CSVConfig.delimiter(',').noEscape().quote(''));
I think this would eliminate the need for static imports.
So far I've implemented methods for changing delimiter, commentStart,
escape and quote policy (have a look at CSVFormatModifierTest). The
approach has the advantage of being short like the initial implementation,
while making sure that CSVFormat is immutable and validated at construction
time. The draw back however is, that it is a bit of a pain to get all the
static imports in place (at least this is my feeling with Eclipse, any
suggestions on how to work efficiently with static imports in eclipse are
appreciated :)
Now I'd like to ask you for feedback. Do you like this approach? Any
suggestions?
One thing I'm not sure about is MutableCSVFormat. Maybe this can be merged
together with CSVFormatModifier.
Regards,
Benedikt
[1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
[2] http://markmail.org/message/vjjdbckwr4dlqp2b
[3] https://github.com/britter/apache-commons-csv-mirror
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [parent][io] v29 and jacoco
On Mon, May 20, 2013 at 5:38 PM, Luc Maisonobe l...@spaceroots.org wrote: Gary Gregory garydgreg...@gmail.com a écrit : Hi All: I updated my local POM for [io] to commons-parent 29 and ran mvn site. The Jacoco report shows FileUtils at 0% which makes no sense since we have a FileUtilsTestCase class. Can anyone reproduce this? I'm not in front of my computer right now. Do the tests end up with expected exceptions using the junit4 annotation @Test(expected=SomeException.class) I think such expected failures are not handled properly yet by Jacoco. Sigh, I think it is a different issue because as far as I can tell all of the test that call FileUtils do not use the expected attribute. In fact 90% of the test classes are JUnit 3 tests and just one test class is a JUnit 4 test case. This makes Cobertura shine in comparison, and the HTML reports where much nicer too. Gary Luc Thank you, Gary -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [parent][io] v29 and jacoco
On Mon, May 20, 2013 at 8:46 PM, Gary Gregory garydgreg...@gmail.comwrote: On Mon, May 20, 2013 at 5:38 PM, Luc Maisonobe l...@spaceroots.org wrote: Gary Gregory garydgreg...@gmail.com a écrit : Hi All: I updated my local POM for [io] to commons-parent 29 and ran mvn site. The Jacoco report shows FileUtils at 0% which makes no sense since we have a FileUtilsTestCase class. Can anyone reproduce this? I'm not in front of my computer right now. Do the tests end up with expected exceptions using the junit4 annotation @Test(expected=SomeException.class) I think such expected failures are not handled properly yet by Jacoco. Sigh, I think it is a different issue because as far as I can tell all of the test that call FileUtils do not use the expected attribute. In fact 90% of the test classes are JUnit 3 tests and just one test class is a JUnit 4 test case. This makes Cobertura shine in comparison, and the HTML reports where much nicer too. Ah, you must be referring to this FAQ entry http://www.eclemma.org/faq.html#trouble02 which is trouble indeed; it's a 'feature' it seems. Back to Cobertura for me unless someone else has a better idea for a tool that actually, well, you know 'covers'... Gary Gary Luc Thank you, Gary -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: Creating CSVFormats (again :)
The CSVConfig solution is better IMO.
The issue with static imports is only an issue if the api is not fluent
(delimiter, comment ...). If after one or two static imports (without * ;)
you get what i called a real builder (a fluent api) it is far easier to
enter the api.
JUnit is different cause you dont configure/build sthg, you just call sthg
line by line.
Le 21 mai 2013 00:42, sebb seb...@gmail.com a écrit :
On 20 May 2013 21:07, Romain Manni-Bucau rmannibu...@gmail.com wrote:
Hi
A real inline builder (withDelimiter(...)...) is better to get completion
and linear reading of the code IMO
What do you mean exactly by a real builder?
Please show the exact syntax.
Static imports are not fine for everbody from my experience
Nothing is going to be fine for everybody.
But static imports seem to work quite well for JUnit4.
Le 20 mai 2013 22:05, Benedikt Ritter brit...@apache.org a écrit :
Hi guys,
a while back we had this discussion [1] about the current state of the
CSVFormat API. We were still not completely happy with it and Oliver
came
up with a new suggestion [2].
This weekend I finally had some time to hack something together. I've
created a mirror of CSV rev. 1484347 at github [3].
This proposal uses CSVFormatModifier objects to change a CSVFormat. The
API
relies on static imports of factory methods for CSVFormatModifiers and
looks like the following:
CSVFormat modifed = CSVFormat.DEFAULT.with(
I don't like the DEFAULT; seems to me it could be dropped.
delimiter(';'),
noEscape(),
commentStart('#'));
Also, I think one could chain the method parameters like so:
CSVFormat modifed =
CSVFormat.using(CSVConfig.delimiter(',').noEscape().quote(''));
I think this would eliminate the need for static imports.
So far I've implemented methods for changing delimiter, commentStart,
escape and quote policy (have a look at CSVFormatModifierTest). The
approach has the advantage of being short like the initial
implementation,
while making sure that CSVFormat is immutable and validated at
construction
time. The draw back however is, that it is a bit of a pain to get all
the
static imports in place (at least this is my feeling with Eclipse, any
suggestions on how to work efficiently with static imports in eclipse
are
appreciated :)
Now I'd like to ask you for feedback. Do you like this approach? Any
suggestions?
One thing I'm not sure about is MutableCSVFormat. Maybe this can be
merged
together with CSVFormatModifier.
Regards,
Benedikt
[1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
[2] http://markmail.org/message/vjjdbckwr4dlqp2b
[3] https://github.com/britter/apache-commons-csv-mirror
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
-
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 JCI -
Continue test if possible; use 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: 108 X-Continuum-Project-Name: Commons JCI Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=26947projectId=108 Build statistics: State: Failed Previous State: Failed Started at: Tue 21 May 2013 05:29:01 + Finished at: Tue 21 May 2013 05:30:53 + Total time: 1m 51s Build Trigger: Schedule Build Number: 4 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: sebb @ Sun 19 May 2013 10:53:43 + Comment: LANG-894 some doap files have incorrect download page Files changed: /commons/proper/betwixt/trunk/doap_betwixt.rdf ( 1484266 ) /commons/proper/cli/trunk/doap_cli.rdf ( 1484266 ) /commons/proper/compress/trunk/doap_compress.rdf ( 1484266 ) /commons/proper/daemon/trunk/doap_daemon.rdf ( 1484266 ) /commons/proper/dbcp/trunk/doap_dbcp.rdf ( 1484266 ) /commons/proper/email/trunk/doap_email.rdf ( 1484266 ) /commons/proper/exec/trunk/doap_exec.rdf ( 1484266 ) /commons/proper/fileupload/trunk/doap_fileupload.rdf ( 1484266 ) /commons/proper/jci/trunk/doap_jci.rdf ( 1484266 ) /commons/proper/lang/trunk/doap_lang.rdf ( 1484266 ) /commons/proper/math/trunk/doap_math.rdf ( 1484266 ) /commons/proper/scxml/trunk/doap_scxml.rdf ( 1484266 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -fae -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Continue test if possible; use Java 1.5 Test Summary: Tests: 56 Failures: 1 Errors: 0 Success Rate: 98 Total time: 80.388 Test Failures: EclipseJavaCompilerTestCase testAdditionalTopLevelClassCompile : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: The type AdditionalTopLevel collides with a package, expected:0 but was:1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.apache.commons.jci.compilers.AbstractCompilerTestCase.testAdditionalTopLevelClassCompile(AbstractCompilerTestCase.java:336) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at
