Re: Creating a commons release
Thanks, got that sorted. Now I have a new question.
I've got a gpg key; I checked the public key into
https://svn.apache.org/repos/asf/commons/trunks-proper/KEYS
in revision 751205.
The KEYS file header says I'm supposed to scp it to
people.apache.org:/www/www.apache.org/dist/commons
I don't have permission to write to that file. It's group-writeable, and
the group is "commons". Apparently my user ("dfabulich") on
people.apache.org is not yet a member of the commons group?
Other than that, I think I'm ready to stage dbutils 1.2 RC1. If anyone
sees an obvious problem now, please let me know.
-Dan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of "CreatingReleases" by DanFabulich
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The following page has been changed by DanFabulich: http://wiki.apache.org/commons/CreatingReleases -- Here you find a list of reminders what to double-check before cutting a release candidate * Make sure that you are not referencing any SNAPSHOT version (dependencies and plugins) otherwise the release will fail - * Make sure that you update your ''changes.xml'' to reflect your release + * Make sure that you update the ''xdocs/changes.xml'' file to reflect your release - * Make sure that all your files contain a ASF licence header (look at the ''RAT'' report when in doubt) + * Make sure that all your files contain a ASF licence header (look at the ''RAT'' report when in doubt, generated with ''mvn site'') * Make sure that the LICENSE and NOTICE files are present and correct - especially that the year is correct in the NOTICE file. * Make sure that you make a test build using a clean checkout * Make sure that there are no major bugs in JIRA - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Creating a commons release
The source for the changes report is xdocs/changes.xml. There's nothing for 1.2 in there currently. I look at the 1.2 JIRA issues and transfer, then do an svn log and look for anything that didn't get a JIRA issue. When you run mvn site, the RAT report is one of the ones that is generated. Hen On Fri, Mar 6, 2009 at 6:35 PM, Dan Fabulich wrote: > > I'm reading the documentation here (is this the most up-to-date?) > http://wiki.apache.org/commons/CreatingReleases > > It says to make sure my changes.xml has been updated. I've done a number of > Maven releases before, though not in commons, and I'm not familiar with that > particular file. Where do I get one? How do I update it? > > Also... > > How do I run a RAT report in commons? Is it being run for me by gump? If > so, where is its output? > > -Dan > > - > 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 a commons release
I'm reading the documentation here (is this the most up-to-date?) http://wiki.apache.org/commons/CreatingReleases It says to make sure my changes.xml has been updated. I've done a number of Maven releases before, though not in commons, and I'm not familiar with that particular file. Where do I get one? How do I update it? Also... How do I run a RAT report in commons? Is it being run for me by gump? If so, where is its output? -Dan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release of CLI 1.2 RC4
Henri Yandell wrote: > No worries - I've gone 1.5 on all Commons libraries in attitude, so my > sloppy fault for not realizing and building this under 1.4. > > Feel free to commit a fix (or I can in time). I'll then build and mail > you and Oliver privately for sign off, then bring back to the list :) Done :) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Local lookup fix & enhancement
On Mar 6, 2009, at 12:59 PM, Jörg Schaible wrote:
Hi folks,
it has been a while since I committed last time something to
configuration.
It has been improved a lot since then and one of the newer features
are the
user defined StrLookup support. However, nothing is perfect and I'd
like to
work somewhat on it. My proposed
1/ While it is quite easy to register a global StrLookup, it is not
so easy
to work with the local ones. Especially since those are no longer
available
for a SubsetConfiguration:
moduleA.value=${my:foo}
assertEquals("bar", config.getString("moduleA.value"));
assertEquals("bar", config.subset("moduleA").getString("value"));
The second assert fails. I've prepared patches to support this
scenario.
This makes sense. But the same thing needs to work it if is a
HierarchicalConfiguration. So if the caller does
config.configurationAt("moduleA").getString("value") it needs to also
work.
Also, make sure any patches also get applied to the experimental
branch. In general, the goal of the experimental branch is to only
deal with hierarchical configurations and treat property files as just
a simpler variation of that.
2/ In my use case I have a big "unified" configuration, actually
based on a
CompositeConfiguration with an overloaded createInterpolator method.
The
configuration itself combines system properties, an individual
configuration for a module and a default configuration file. Each
module
will use then its own subset (so it can be used or tested
individually),
but the scenario allows me to override every configuration value from
command line or use a default value in the standard file. However,
sometimes the individual modules share some settings and therefore I
invented auto-lookups based on a local StrLookup. These auto-lookup
are
defined automatically using the keys in the configuration itself, i.e.
auto.lookup.ldap.host=localhost
auto.lookup.ldap.port=636
auto.lookup.ldap.base=dc=apache,dc=org
auto.lookup.wsdl.serviceA=http://localhost:4711/serviceA
auto.lookup.wsdl.serviceB=http://localhost:4711/serviceB
moduleA.serviceA=${wsdl:serviceA}
moduleA.ldap.url=ldap://${ldap:host}:${ldap:port}/${ldap:base}
moduleB.serviceB=${wsdl:serviceB}
moduleB.ldap.url=ldap://${ldap:host}:${ldap:port}/${ldap:base}
moduleC.serviceA=${wsdl:serviceA}
moduleC.serviceB=${wsdl:serviceB}
Explanation:
- "auto.lookup" defines the root node for the automatically
registered local
lookups (the name of this root can be set individually for a
configuration)
- the next node defines the namespace of the lookup
- all nodes below "auto.lookup.XXX" are part of the local lookup
- even for subsets of the individual modules these local auto-
lookups work:
config.subset("moduleA").getString("serviceA")
As said I've implemented this currently in a derived class of
CompositeConfiguration, but it might be added to
AbstractConfiguration. The
name of the auto-lookup root is provided as ctor param. The local
StrLookup
itself is again based on a Configuration (actually a subset of the
name
giving node).
WDYT?
I tend not to use CompositeConfiguration - we only use
HierarchicalConfigurations which CompositeConfiguration unfortunately
doesn't support.
Basically it looks like you created a new Lookup class and a way to
populate data the Lookup uses. I'm OK with that. However, the devil is
in the details. How the Lookup gets populated from the Configuration
would be worth a look-see. Again, this feature should also work for
HierarchicalConfigurations.
Just as an FYI - I have made some enhancements to allow Commons
Configuration to leverage Commons VFS. I haven't committed them
because they need the latest Commons VFS code and since those haven't
been released the Commons Configuraton build would fail. Commons VFS
won't be required at runtime unless the user wants to take advantage
of this.
Ralph
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release of CLI 1.2 RC4
No worries - I've gone 1.5 on all Commons libraries in attitude, so my
sloppy fault for not realizing and building this under 1.4.
Feel free to commit a fix (or I can in time). I'll then build and mail
you and Oliver privately for sign off, then bring back to the list :)
Hen
On Fri, Mar 6, 2009 at 10:57 AM, Jörg Schaible wrote:
> Hi Henri,
>
> maybe I should have really commit my patch, because no we have:
>
>
> = %<
> joe...@paddy ~/java/commons-cli-1.2-src $ java-config -s sun-jdk-1.4
> Now using sun-jdk-1.4 as your user JVM
> joe...@paddy ~/java/commons-cli-1.2-src $ mvn clean package
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Commons CLI
> [INFO] task-segment: [clean, package]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory /home/joehni/java/commons-cli-1.2-src/target
> [INFO] [antrun:run {execution: javadoc.resources}]
> [INFO] Executing tasks
> [copy] Copying 2 files
> to /home/joehni/java/commons-cli-1.2-src/target/apidocs/META-INF
> [INFO] Executed tasks
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 20 source files
> to /home/joehni/java/commons-cli-1.2-src/target/classes
> [INFO] [bundle:manifest {execution: bundle-manifest}]
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Compiling 24 source files
> to /home/joehni/java/commons-cli-1.2-src/target/test-classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
>
> /home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
> [205,34] cannot resolve symbol
> symbol : method contains (java.lang.String)
> location: class java.lang.String
>
> /home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
> [206,34] cannot resolve symbol
> symbol : method contains (java.lang.String)
> location: class java.lang.String
>
> /home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
> [213,34] cannot resolve symbol
> symbol : method contains (java.lang.String)
> location: class java.lang.String
>
> /home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
> [214,34] cannot resolve symbol
> symbol : method contains (java.lang.String)
> location: class java.lang.String
>
>
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 13 seconds
> [INFO] Finished at: Fri Mar 06 19:52:05 CET 2009
> [INFO] Final Memory: 11M/26M
> [INFO]
>
> = %<
>
> I am really sorry, don't kill the messenger ;-)
>
> - 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
[configuration] Local lookup fix & enhancement
Hi folks,
it has been a while since I committed last time something to configuration.
It has been improved a lot since then and one of the newer features are the
user defined StrLookup support. However, nothing is perfect and I'd like to
work somewhat on it. My proposed
1/ While it is quite easy to register a global StrLookup, it is not so easy
to work with the local ones. Especially since those are no longer available
for a SubsetConfiguration:
moduleA.value=${my:foo}
assertEquals("bar", config.getString("moduleA.value"));
assertEquals("bar", config.subset("moduleA").getString("value"));
The second assert fails. I've prepared patches to support this scenario.
2/ In my use case I have a big "unified" configuration, actually based on a
CompositeConfiguration with an overloaded createInterpolator method. The
configuration itself combines system properties, an individual
configuration for a module and a default configuration file. Each module
will use then its own subset (so it can be used or tested individually),
but the scenario allows me to override every configuration value from
command line or use a default value in the standard file. However,
sometimes the individual modules share some settings and therefore I
invented auto-lookups based on a local StrLookup. These auto-lookup are
defined automatically using the keys in the configuration itself, i.e.
auto.lookup.ldap.host=localhost
auto.lookup.ldap.port=636
auto.lookup.ldap.base=dc=apache,dc=org
auto.lookup.wsdl.serviceA=http://localhost:4711/serviceA
auto.lookup.wsdl.serviceB=http://localhost:4711/serviceB
moduleA.serviceA=${wsdl:serviceA}
moduleA.ldap.url=ldap://${ldap:host}:${ldap:port}/${ldap:base}
moduleB.serviceB=${wsdl:serviceB}
moduleB.ldap.url=ldap://${ldap:host}:${ldap:port}/${ldap:base}
moduleC.serviceA=${wsdl:serviceA}
moduleC.serviceB=${wsdl:serviceB}
Explanation:
- "auto.lookup" defines the root node for the automatically registered local
lookups (the name of this root can be set individually for a configuration)
- the next node defines the namespace of the lookup
- all nodes below "auto.lookup.XXX" are part of the local lookup
- even for subsets of the individual modules these local auto-lookups work:
config.subset("moduleA").getString("serviceA")
As said I've implemented this currently in a derived class of
CompositeConfiguration, but it might be added to AbstractConfiguration. The
name of the auto-lookup root is provided as ctor param. The local StrLookup
itself is again based on a Configuration (actually a subset of the name
giving node).
WDYT?
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release of CLI 1.2 RC4
Hi Henri,
maybe I should have really commit my patch, because no we have:
= %<
joe...@paddy ~/java/commons-cli-1.2-src $ java-config -s sun-jdk-1.4
Now using sun-jdk-1.4 as your user JVM
joe...@paddy ~/java/commons-cli-1.2-src $ mvn clean package
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons CLI
[INFO]task-segment: [clean, package]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/joehni/java/commons-cli-1.2-src/target
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files
to /home/joehni/java/commons-cli-1.2-src/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 20 source files
to /home/joehni/java/commons-cli-1.2-src/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 24 source files
to /home/joehni/java/commons-cli-1.2-src/target/test-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
[205,34] cannot resolve symbol
symbol : method contains (java.lang.String)
location: class java.lang.String
/home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
[206,34] cannot resolve symbol
symbol : method contains (java.lang.String)
location: class java.lang.String
/home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
[213,34] cannot resolve symbol
symbol : method contains (java.lang.String)
location: class java.lang.String
/home/joehni/java/commons-cli-1.2-src/src/test/org/apache/commons/cli/OptionGroupTest.java
[214,34] cannot resolve symbol
symbol : method contains (java.lang.String)
location: class java.lang.String
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 13 seconds
[INFO] Finished at: Fri Mar 06 19:52:05 CET 2009
[INFO] Final Memory: 11M/26M
[INFO]
= %<
I am really sorry, don't kill the messenger ;-)
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r750313 - /commons/sandbox/compress/trunk/src/test/java/org/apache/commons/compress/AbstractTestCase.java
On 06/03/2009, Stefan Bodewig wrote: > On 2009-03-06, sebb wrote: > > > On 06/03/2009, Stefan Bodewig wrote: > >> On 2009-03-06, sebb wrote: > > > >>> Adding back the .getClassLoader() stage improves matters, > > >> That really isn't supposed to make any difference, strange. > > > Class.getResource() makes these changes to the resource name: > > > "if the resource name starts with "/", it is unchanged; otherwise, the > > package name is prepended to the resource name after converting "." to > > "/". " > > > ClassLoader.getResource() does not do this. > > > I knew that (but assumed the path names were startng with a slash), it > shouldn't make any difference WRT whitespace was what I meant. Probably not - but the test does not get that far, as it fails on the first file... > Sorry I was unclear Likewise, I could have been more explicit... > > 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
Re: svn commit: r750313 - /commons/sandbox/compress/trunk/src/test/java/org/apache/commons/compress/AbstractTestCase.java
On 2009-03-06, sebb wrote: > On 06/03/2009, Stefan Bodewig wrote: >> On 2009-03-06, sebb wrote: >>> Adding back the .getClassLoader() stage improves matters, >> That really isn't supposed to make any difference, strange. > Class.getResource() makes these changes to the resource name: > "if the resource name starts with "/", it is unchanged; otherwise, the > package name is prepended to the resource name after converting "." to > "/". " > ClassLoader.getResource() does not do this. I knew that (but assumed the path names were startng with a slash), it shouldn't make any difference WRT whitespace was what I meant. Sorry I was unclear Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r750313 - /commons/sandbox/compress/trunk/src/test/java/org/apache/commons/compress/AbstractTestCase.java
On 2009-03-06, Christian Grobmeier wrote: >> Could anybody using Eclipse please check whether the appended trivial >> patch causes problems there? > Your patch works for me with Eclipse Ganymede and Mac OSX 10.5. It should as long as your current working directory is set correctly, but then again this is true for the old addURL version as well. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r750313 - /commons/sandbox/compress/trunk/src/test/java/org/apache/commons/compress/AbstractTestCase.java
On 06/03/2009, Christian Grobmeier wrote: > > Could anybody using Eclipse please check whether the appended trivial > > patch causes problems there? > > > Your patch works for me with Eclipse Ganymede and Mac OSX 10.5. Also on WinXP. > The addUrl Method looks like not used anymore, it can be removed imho. Agreed. > It has appeared cause of the getClass.getResource approach. The new > stuff is lots better, so lets kick it out. > > Best, > > Christian > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r750313 - /commons/sandbox/compress/trunk/src/test/java/org/apache/commons/compress/AbstractTestCase.java
On 06/03/2009, Stefan Bodewig wrote: > On 2009-03-06, sebb wrote: > > > On 05/03/2009, bode...@apache.org wrote: > > > >> URL: http://svn.apache.org/viewvc?rev=750313&view=rev > >> Log: > >> make tests pass on Linux > > > However, they now fail on Windows (and compilation fails on Java > > 1.4/1.5, but I fixed that). > > > Sorry about the Java6ism. > > > > Adding back the .getClassLoader() stage improves matters, > > > That really isn't supposed to make any difference, strange. > Class.getResource() makes these changes to the resource name: "if the resource name starts with "/", it is unchanged; otherwise, the package name is prepended to the resource name after converting "." to "/". " ClassLoader.getResource() does not do this. I've no idea why, but that's what the Javadoc for 1.4 says. > > > but then the ChangeSetTestCase tests fail with > > > java.io.IOException: Illegal character in path > > > which is caused by the space character. > > > The File -> URI and URI -> File conversions have always been > problematic. I had hoped new File(URI) would work - didn't test on > Windows, obviously). > > The IOException probably is wrapping an URISyntaxException, which > means URL.toString() has returned an illegal URI on your JDK, great. > Looks like it. This was on Win/XP using java version "1.4.2_17" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_17-b06) Java HotSpot(TM) Client VM (build 1.4.2_17-b06, mixed mode) Works fine using: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04) So it does appear to be a Java bug. > > > I'm not sure that getResource() is the correct method to use here. > > > Well, it works great for files that don't contain spaces in their name > 8-) Only if you use the ClassLoader version. I checked the Continuum build and it reports file not found for test1.xml. > A hack could be to check whether the file name contains spaces and > locate the parent directory instead of the file itself - or use > getResourceAsStream in all tests that want to use files with spaces in > their names - neither approach looks nice, but I'm not sure how to > locate the files from the resources without hardcoding paths. > > 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
[g...@vmgump]: Project commons-compress-test (in module commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-compress-test 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-compress-test : Apache commons sandbox Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/commons-sandbox/compress/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/commons-sandbox/compress/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/compress/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/commons-sandbox/compress/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress-test/gump_work/build_commons-sandbox_commons-compress-test.html Work Name: build_commons-sandbox_commons-compress-test (Type: Build) Work ended in a state of : Failed Elapsed: 56 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/commons-sandbox/compress/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/commons-sandbox/compress] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/commons-sandbox/compress/target/commons-compress-1.0-SNAPSHOT.jar - Running org.apache.commons.compress.changes.ChangeSetTestCase Tests run: 13, Failures: 0, Errors: 11, Skipped: 0, Time elapsed: 0.056 sec <<< FAILURE! Results : Tests in error: testGzipCreation(org.apache.commons.compress.compressors.GZipTestCase) testGzipUnarchive(org.apache.commons.compress.compressors.GZipTestCase) testJarArchiveCreation(org.apache.commons.compress.archivers.JarTestCase) testJarUnarchive(org.apache.commons.compress.archivers.JarTestCase) testJarUnarchiveAll(org.apache.commons.compress.archivers.JarTestCase) testBzipCreation(org.apache.commons.compress.compressors.BZip2TestCase) testBzip2Unarchive(org.apache.commons.compress.compressors.BZip2TestCase) testCpioArchiveCreation(org.apache.commons.compress.archivers.CpioTestCase) testCpioUnarchive(org.apache.commons.compress.archivers.CpioTestCase) testZipArchiveCreation(org.apache.commons.compress.archivers.ZipTestCase) testZipUnarchive(org.apache.commons.compress.archivers.ZipTestCase) testUtf8Interoperability(org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest) testTarArchiveCreation(org.apache.commons.compress.archivers.TarTestCase) testTarArchiveLongNameCreation(org.apache.commons.compress.archivers.TarTestCase) testTarUnarchive(org.apache.commons.compress.archivers.TarTestCase) testArArchiveCreation(org.apache.commons.compress.archivers.ArTestCase) testArUnarchive(org.apache.commons.compress.archivers.ArTestCase) testDeleteDir(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteFile(org.apache.commons.compress.changes.ChangeSetTestCase) testDeletePlusAdd(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteFromAndAddToZip(org.apache.commons.compress.changes.ChangeSetTestCase) testAddDeleteAdd(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteAddDelete(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteFromZip(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteFromTar(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteFromJar(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteFromAndAddToTar(org.apache.commons.compress.changes.ChangeSetTestCase) testDeleteFromAndAddToJar(org.apache.commons.compress.changes.ChangeSetTestCase) Tests run: 70, Failures: 0, Errors: 28, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/commons-sandbox/compress/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 54 seconds [INFO] Finished at: Fri Mar 06 01:46:26 GMT-08:00 2009 [INFO] Final Memory: 14M/2
