[compress] encoding in tar package

Hi all, I've been working on COMPRESS-183 which is a more general version of COMPRESS-114 we fixed a while ago. It asks for support of non-ASCII file names in tar archives by using an explicit encoding (COMPRESS-114 made things work for ISO-8859-1 and any other encoding that creates the same byte

[compress] Releasing 1.4

Hi all, Compress' trunk has been sitting on valuable content for too long now: * XZ compression * BZIP2 now reads streams created by pbzip2 (parallel bzip2) * TAR has been largely improved to support reading and writing big files, old files and files with long names - as well as encodings o

Re: [compress] Releasing 1.4

On 2012-03-31, sebb wrote: > There are a few places where the default charset is being used. > It's not clear whether these are intentional or not, so I have marked > them with TODOs. Thanks (and thanks for the other fixes as well). > We should either document that the default is OK, or use a fi

Re: [compress] Releasing 1.4

On 2012-03-31, Christian Grobmeier wrote: > Before ages when I wrote the "ChangeSet" stuff I have marked them as > "experimental". Have not heard any complains yet... we should discuss > if we remove that label or if need some more tweaks there. Probably > after 1.4? I must admit I've never used

Re: [compress] Releasing 1.4

On 2012-03-31, Gary Gregory wrote: > The trunk looks good now IMO. I'll let others decide about the change set > docs. > The only item that stick out but could wait for another release: > - the large code dup in BZip2CompressorInputStream as noted by CPD. I've seen that but must admit I didn't s

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

On 2012-04-01, Ralph Goers wrote: > I have real problems with Gump. I find it very difficult to determine > what the problem actually is much less diagnose it. Other than that I > know it is supposed to be using the latest source in trunk it is tough > to figure out how to reproduce a problem as i

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

On 2012-04-01, Ralph Goers wrote: > From the vfs2 log it looks like it is running into a binary > incompatibility with SLF4J. vfs2 is specifying SLF4J 1.5.5 but mvn > dependency:tree is showing me that Jackrabbit is referencing > jcl-over-slf4j and is using 1.5.3. I've added that to the vfs2 pom

Re: [compress] Releasing 1.4

On 2012-04-01, Christian Grobmeier wrote: > On Sun, Apr 1, 2012 at 7:01 AM, Stefan Bodewig wrote: >> On 2012-03-31, Christian Grobmeier wrote: >>> Before ages when I wrote the "ChangeSet" stuff I have marked them as >>> "experimental". Have n

[VOTE] Release Compress 1.4 based on RC1

Hi all, as indicated last weekend Compress' trunk has accumulated so much new goodness it requires a new release. Tarballs of Compress 1.4 RC1 are available here http://people.apache.org/~bodewig/commons-compress-1.4RC1/ Maven artifacts are here: https://repository.apache.org/conten

Re: [VOTE] Release Compress 1.4 based on RC1

On 2012-04-05, sebb wrote: > On 4 April 2012 21:00, Stefan Bodewig wrote: >>    http://people.apache.org/~luckyrm/foo-1.2-RC1/site/ > Does not exist; looks like a left-over from an e-mail template. *blush* - sorry. A bit too much copy-paste

Re: [VOTE] Release Compress 1.4 based on RC1

On 2012-04-05, Emmanuel Bourg wrote: > The new Charsets class in the utils package is not used by the code. I > think it should be removed from the API. I'd would also argue that > CharsetNames has not its place in [compress], I would rather stick to > strings and rely on [io] or [lang] to provide

Re: [VOTE] Release Compress 1.4 based on RC1

On 2012-04-05, Emmanuel Bourg wrote: > The new Charsets class in the utils package is not used by the code. I > think it should be removed from the API. I'd would also argue that > CharsetNames has not its place in [compress], I would rather stick to > strings and rely on [io] or [lang] to provide

Re: [VOTE] Release Compress 1.4 based on RC1

Oops, I never voted explicitly. On 2012-04-04, Stefan Bodewig wrote: > as indicated last weekend Compress' trunk has accumulated so much new > goodness it requires a new release. > Tarballs of Compress 1.4 RC1 are available here > http://people.apache.org/~bodewig/common

[RESULT] Passed: Release Compress 1.4 based on RC1

Hi all, the vote has passed with six +1s (sebb, Gary, Oliver, Torsten, Jörg and myself) and no other votes. I'll now proceed with the release process. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For add

[ANNOUNCE] Apache Commons Compress 1.4 Released

100 characters. For complete information on Commons Compress, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Compress website: http://commons.apache.org/compress/ Stefan Bodewig, on behalf of the Apache Commons comm

Re: svn commit: r1326609 - in /commons/proper/io/trunk/src: changes/changes.xml main/java/org/apache/commons/io/FileUtils.java

On 2012-04-16, wrote: > [IO-324] Add Charset sister APIs to method that take a String charset name. The new methods cause problems for people who pass in null for the charset as they want the platform's system default. The compiler doesn't know which of the writeStringToFile methods to pick if

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Compress - Default Maven 2 Build Definition (Java 1.5)

On 2012-05-21, sebb wrote: > FIxed Thanks! When merging the changes to Ant I ran into conflicts and resolved one hunk the wrong way around by accident (and didn't realize I was changing more than the comments on the subsequent commit). For some reason I also missed the Continuum build failure.

[VOTE] Release Compress 1.4.1 based on RC1

Hi all, I'd like to release Compress 1.4.1. Compress 1.4.1 RC1 is available for review here: http://people.apache.org/~bodewig/cc/ Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-111/org/apache/commons/commons-compress/1.4.1/ Details of

Re: [VOTE] Release Compress 1.4.1 based on RC1

On 2012-05-22, Stefan Bodewig wrote: > I'd like to release Compress 1.4.1. > Compress 1.4.1 RC1 is available for review here: > http://people.apache.org/~bodewig/cc/ > The tag is here: > > https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRES

Re: [VOTE] Release Compress 1.4.1 based on RC1

On 2012-05-22, Gary Gregory wrote: > [X] -0 OK, but really should fix... > - The logo is missing its "TM" per Apache branding requirements. The "commons compress" logo in the upper right corner? It is the same logo as the one that's currently online. Anyway, we can fix the site independent of

Re: [VOTE] Release Compress 1.4.1 based on RC1

On 2012-05-22, Gary Gregory wrote: > I fixed the logo in SVN ;) Great, thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

[RESULT] Release Compress 1.4.1 based on RC1

Hi all, the vote has passed with +1s by Luc, Christian, Oliver and myself. I'll now go ahead and publish the tarballs. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h..

[CVE-2012-2098] Apache Commons Compress and Apache Ant denial of service vulnerability

.html http://ant.apache.org/security.html Stefan Bodewig pgpuZAA6eT3Zt.pgp Description: PGP signature

[compress] encoding parameter in ArchiveStreamFactory (was Re: svn commit: r1358626)

On 2012-07-08, sebb wrote: > On 7 July 2012 20:34, wrote: >> Modified: >> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/ArchiveStreamFactory.java >>+private String entryEncoding = null; > The class is currently tagged as: > * @Immutable > This breaks t

Re: [compress] patch to TarArchiveEntry for detecting a symlink

On 2010-10-27, Max Birkoff wrote: > I had approached the ant project with this request (as I had been > using the tar under org.apache.tools.tar.TarEntry that ships with ant) > but Stefan Bodewig directed me here. Suggested this would be the better place 8-) > If this patch is acc

[g...@vmgump]: Project commons-jci-core (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-jci-core has an issue affecting its community integration. This is

[g...@vmgump]: Project commons-jci-fam (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-jci-fam has an issue affecting its community integration. This iss

[g...@vmgump]: Project commons-jci-core (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-jci-core has an issue affecting its community integration. This is

[g...@vmgump]: Project commons-jci-core (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-jci-core has an issue affecting its community integration. This is

[lang3] Test Fail in Headless Mode (at Least on a Mac)

Hi, I'm pretty sure lang3 isn't the only project that is affected, it's just the first one we've seen it. "we" ist the Gump project. Sander has set up a Mac to run Gump[1] and commons-lang3 is Gump's guinea pig for Maven 3.x builds in the workspace we use for developer tests and new installation

Re: [lang3] Test Fail in Headless Mode (at Least on a Mac)

On 2010-11-22, Jörg Schaible wrote: > Stefan Bodewig wrote: >> The commons-lang3 builds fail[2] and too me it looks as if this was >> because AWT is not running in headless mode, confirmed by passing -DargLine=-Djava.awt.headless=true to mvn - the builds now pass. >> I am

Re: [lang3] Test Fail in Headless Mode (at Least on a Mac)

On 2010-11-24, sebb wrote: > On 24 November 2010 09:46, Stefan Bodewig wrote: >> On 2010-11-22, Jörg Schaible wrote: >>> Stefan Bodewig wrote: >>>> The commons-lang3 builds fail[2] and too me it looks as if this was >>>> because AWT is not running

Re: [lang3] Test Fail in Headless Mode (at Least on a Mac)

On 2010-12-01, Henri Yandell wrote: > I've fixed this in r1040879. I can confirm it is fixed for Gump as well. I removed all awt.headless settings from the Gump descriptor and the build still passes on adam. Thanks! Stefan -

Re: [g...@vmgump]: Project commons-net (in module apache-commons) failed

Hi, This - and most other mvn built projects - fail during the current Gump run because the Maven repo returns an HTML page indicating a 404 error for the SHA1 checksums. Maven seems to ignore the HTTP er

Re: [g...@vmgump]: Project commons-net (in module apache-commons) failed

On 2010-12-02, sebb wrote: > On 2 December 2010 11:10, Stefan Bodewig wrote: >> This - and most other mvn built projects - fail during the current Gump >> run because the Maven repo returns an HTML page indicating a 404 error >> for the SHA1 checksums. >> <htt

Re: [g...@vmgump]: Project commons-collections4 (in module apache-commons) failed

On 2010-12-08, Gump wrote: > /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[68,38] > invalid inferred types for T; actual arguments do not conforms to inferred > formal arguments > required: org.apache.commons.collec

[g...@vmgump]: Project commons-jci-core (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-jci-core has an issue affecting its community integration. This is

[attributes] Gump failure after qdox update

On 2011-02-11, Gump wrote: > [javac] > /srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245: > incompatible types > [javac] found : com.thoughtworks.qdox.model.JavaPackage > [javac] required: java.l

Re: [GUMP@vmgump]: Project commons-vfs (in module commons-vfs-1.x) failed

On 2011-03-03, Gump wrote: > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /srv/gump/public/workspace/commons-vfs-1.x/examples/src/main/java/org/apache/commons/vfs/libcheck/FtpCheck.java:[75,46] > cannot find symbol > symbol : met

[VFS] Is it OK to upgrade commons-net to 2.2?

Hi, the recent Gump failures occur because commons-net has removed a deprecated method that VFS uses. The recommended replacement of the method is not available in commons-net 2.0 (which trunk depends on) so in order to adapt to the changes VFS would need to upgdare to commons-net 2.2. Would suc

Re: [VFS] Is it OK to upgrade commons-net to 2.2?

On 2011-03-04, Jörg Schaible wrote: > Stefan Bodewig wrote: >> the recent Gump failures occur because commons-net has removed a >> deprecated method that VFS uses. The recommended replacement of the >> method is not available in commons-net 2.0 (which trunk depends on) so

Re: [VFS] Is it OK to upgrade commons-net to 2.2?

Hi Jörg, On 2011-03-04, Jörg Schaible wrote: > Since gump messages came in: vfs-1 will not be updated anyway ... As in "vfs-1 is no longer under any kind of development"? If so, we should probably remove it from Gump anyway. Stefan -

Re: [VFS] Is it OK to upgrade commons-net to 2.2?

On 2011-03-04, Jörg Schaible wrote: > Stefan Bodewig wrote: >> On 2011-03-04, Jörg Schaible wrote: >>> Since gump messages came in: vfs-1 will not be updated anyway ... >> As in "vfs-1 is no longer under any kind of development"? > Yes. >> If so, we

Re: [VFS] Is it OK to upgrade commons-net to 2.2?

On 2011-03-04, Ralph Goers wrote: > On Mar 4, 2011, at 1:44 AM, Jörg Schaible wrote: >> Actually the usage of net 2.2 would be better then, but Ralph should >> agree in the current vfs stage. > OK - if 2.2 is released then I have no problem in changing the > dependency and changing whatever code

Re: [lang3] Pair

On 2011-03-04, Matt Benson wrote: > Another interesting concept mentioned in this article is the > summarized by the statement "Another way of formalizing tuples is as > nested ordered pairs." I would argue that this is the only efficient > way to formally represent an n-tuple using Java generics

Re: [VFS] Is it OK to upgrade commons-net to 2.2?

On 2011-03-04, Jörg Schaible wrote: > Stefan Bodewig wrote: >> * for the Ant built projects that depend on vfs (Ivy, log4j-chainsaw and >> vfs2-sandbox) I'll make the 1.0 jar available. > When all of them require normally the release, it's fine. Ivy seems to bu

Re: [discovery] dropping the ant stuff

On 2011-04-10, Gary Gregory wrote: > Will that break gump? It would have, yes. The current metadata tell Gump to use Ant for building discovery. Given that discovery doesn't have too many dependencies switching Gump to use mvn instead wouldn't be a big issue. Using mvn for something as high up

Re: svn commit: r1094224 - in /commons/proper/compress/trunk/src: changes/changes.xml main/java/org/apache/commons/compress/archivers/zip/ZipFile.java

On 2011-04-18, Adrian Crum wrote: > A suggestion: if the library has logging capability, then log a > warning saying that the archive was closed in the finalize > method. That will serve as a clue to the library user that they forgot > to close the archive. You are right, but commons-compress doe

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

On 2011-04-18, Phil Steitz wrote: > The problem is that without logging in to vmbuild, there does not > appear to be a way to get to /target and see all the little > surefire-reports files that maven creates so you can see which test > case failed. Does anyone know of a way to get to /target onli

Re: svn commit: r1094224 - in /commons/proper/compress/trunk/src: changes/changes.xml main/java/org/apache/commons/compress/archivers/zip/ZipFile.java

On 2011-04-18, sebb wrote: > On 18 April 2011 06:22, Stefan Bodewig wrote: >> On 2011-04-18, Adrian Crum wrote: >>> A suggestion: if the library has logging capability, then log a >>> warning saying that the archive was closed in the finalize >>> method. That

Re: svn commit: r1094857 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java

On 2011-04-19, sebb wrote: > On 19 April 2011 06:39, wrote: >> URL: >> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1094857&r1=1094856&r2=1094857&view=diff >>

Re: svn commit: r1094856 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java

On 2011-04-19, sebb wrote: > On 19 April 2011 06:35, wrote: >>>        // this flag is only written here and read in finalize() which >>>        // can never be run in parallel. >>>        // no synchronization needed. > Are you sure? At least as long as finalize is not called by anybody else

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

this is the digester => digester3 move. I'll take care of renaming the project in Gump an all that. Meanwhile I assume digester3 won't be binary or even source code compatible with 2.x so we'll need to provide Digester 2.x for the projects depending on it. Are you expecting to ever do a 2.x rele

Re: [ALL] BCEL and JCS as Commons components?

On 2011-06-16, Rahul Akolkar wrote: > As Jakarta winds down, we are looking for sustainable homes for couple > of Java libraries -- BCEL [1] and JCS [2]. These aren't very different > from many Commons libraries in size, number of developers, list > traffic etc. Would Commons be interested in acce

Re: [VOTE] Accept BCEL and JCS as Commons components

On 2011-06-26, Rahul Akolkar wrote: > This is half a dozen related votes in one thread (for convenience), namely: > 1. Accept BCEL [1] as Commons component > 1a. Grant Commons karma to Dave Brosius (dbrosius) > 2. Accept JCS [2] as Commons component > 2a. Grant Commons karma to Aaron Smuts (asmu

Re: [BCEL] Next release

On 2011-07-18, Torsten Curdt wrote: >> I'm all for it. > I say what I've said all this time when questions like this came up. > We need testers! There has been quite few changes. Just releasing > without some people spending some time ...or telling us "yes, trunk > works for me!" I am still not c

Re: [BCEL] Next release

On 2011-07-19, Torsten Curdt wrote: >>> I say what I've said all this time when questions like this came up. >>> We need testers! There has been quite few changes. Just releasing >>> without some people spending some time ...or telling us "yes, trunk >>> works for me!" I am still not comfortable w

[compress] Potential Backwards Incompatible Change to JAR Package

Hi, I was looking through some old stuff we postponed last year when we released Compress 1.1. One of them is COMPRESS-18 where I provided a patch but didn't commit it. Our JAR package doesn't provide the stuff java.util.jar does and is actually pretty useless - there isn't anything in it not pr

Re: [compress] Potential Backwards Incompatible Change to JAR Package

On 2011-07-20, Torsten Curdt wrote: >> Personally I don't expect anybody to use the JAR package at all today >> so I'd do with a warning, apply the patch and keep 1.2 as the version >> number for the next release.  Other options would be the "convoluted >> implementation", "just don't fix it" or a

Re: [compress] Potential Backwards Incompatible Change to JAR Package

On 2011-07-20, Gary Gregory wrote: > On Wed, Jul 20, 2011 at 5:30 PM, Torsten Curdt wrote: >>> Personally I don't expect anybody to use the JAR package at all today >>> so I'd do with a warning, apply the patch and keep 1.2 as the version >>> number for the next release.  Other options would be t

[compress] Require Java5?

Hi, no, this is not about generics or enums or ... This time it is methods added in the classlib, in particular java.util.zip.Inflater#getBytesRead and friends which return longs rather than ints that are returned by getTotalIn. Since ZIP entry size is an unsigned four byte int even without Zip6

Re: [compress] Require Java5?

On 2011-07-21, Christian Grobmeier wrote: > If we lift up to 1.5 as a minimum what about lifting to compress 2.0? Depends on what we want to do. If we want to break BWC by introducing genrics, then let's do that. I am currently withholding some work I started to get the permissions stuff straig

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

On 2011-07-21, wrote: > The problem seems to come from reading resource test files, see > . > Is there something specific to tell Gump the

Re: [compress] Require Java5?

On 2011-07-21, Christian Grobmeier wrote: > On Thu, Jul 21, 2011 at 10:44 AM, Stefan Bodewig wrote: >> On 2011-07-21, Christian Grobmeier wrote: >>> If we lift up to 1.5 as a minimum what about lifting to compress 2.0? >> Depends on what we want to do.  If we want to

[compress] Proposed Roadmap

Hi all, >From the responses in the Java5 thread I propose the following. (1) Release current trunk minus a few lines of code I already added for initial Zip64 support plus some minor changes ASAP as 1.2 (2) Require Java5, use minimal Java5 language features to make compiler warnings go

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

On 2011-07-21, sebb wrote: > On 21 July 2011 09:48, Stefan Bodewig wrote: >> Done with <http://svn.apache.org/viewvc?view=revision&revision=1149079> >> unless I managed to get the path wrong. > Although that may fix the issue for Gump, I think that's the

[compress] Closing Streams and System.in (COMPRESS-128)

Hi, for reference The bzip2 inputstream checks whether its wrapped input stream is System.in before closing it. Do we want to add the same behavior to all other implementations or do we want to remove it from the bzip2 one and leave it to the

Re: [compress] Proposed Roadmap

Hi, I've moved some JIRA issues that are clear they'll need to break the API to 2.0 and assigned a few JIRAs where a patch is available or I would know how to implement them to 1.2 and 1.3. Please review

Re: [compress] Closing Streams and System.in (COMPRESS-128)

On 2011-07-23, Simone Tripodi wrote: > I personally like more the NoCloseStream approach, it would help > avoiding code redundancies (having the Sysout check pattern repeated > doesn't look nice IMHO) Yes, that would be my preference as well. Stefan -

Re: [compress] Proposed Roadmap

On 2011-07-23, Simone Tripodi wrote: > I think it would be nice having also s pure Java implementation of the > Snappy[1] compression (the Google's compression), Absolutely, it is just a matter of getting it coded 8-) > I found a Java implementation[2] but it's JNI wrapper :/ Well, that could b

[general] where to place custom PMD rules?

Hi, in Compress we have quite a few classes that use constants that deal with Unix permission flags, those are most naturally expressed as octals so I'd like to modify the basic ruleset to exclude the AvoidUsingOctalValues rule. I'm not familiar with the PMD plugin but think the easiest way to do

Re: [compress] Closing Streams and System.in (COMPRESS-128)

On 2011-07-23, sebb wrote: > On 23 July 2011 12:45, Stefan Bodewig wrote: >> On 2011-07-23, Simone Tripodi wrote: >>> I personally like more the NoCloseStream approach, it would help >>> avoiding code redundancies (having the Sysout check pattern repeated >>

Re: [general] where to place custom PMD rules?

On 2011-07-23, Phil Steitz wrote: > On 7/23/11 5:48 AM, Stefan Bodewig wrote: >> I'm not familiar with the PMD plugin but think the easiest way to do >> that is by adding a rules file of my own that "ref"s the basic ruleset >> excluding the octal rule. Is the

[compress] Keep old Javadocs?

Hi all, some components keep the Javadocs for older versions online in addition to the ones of the current release. In our case the Javadocs for 1.2 won't be too different from the ones of 1.1, so I don't think it is worthwhile, but still I'd like to double check. Does anybody want the Javadocs

[compress] Planning the 1.2 Release

Hi all, given that most discussion has only been started late last week, it has been a bit unorganized and some things have moved during the weekend I'll give it a bit more time to settle. IMHO svn trunk is ready to be released and likely won't change except for release notes, version numbers and

Re: [compress] Keep old Javadocs?

On 2011-07-25, wrote: > If the URL do include the version, then it would be better to keep old > version online, to avoid dangling links from external web pages, mail > archives or documentation. Good point, thanks Luc. The Javadoc URLs for Compress currently don't contain a version number so t

Re: [compress] Require Java5?

On 2011-07-21, sebb wrote: > However just doing that without adding @Override and minimal generics > will result in compilation warnings; it seems wromg to release source > that does not compile cleanly. The zip64 branch now requires Java5 but I'm having a hard time seeing any compiler warnings.

[compress] Where to Place Big Test Archives?

Hi, ZIP64 is all about supporting archives with entries bigger than 4GB and archives with more than 65355 entries so it comes as no surprise that test archives for ZIP64 are big. Right now I'm working with two archives, one contains a single file that consists of 5e9 zeros, the InfoZIP generated

Re: [compress] Where to Place Big Test Archives?

On 2011-07-26, Gary Gregory wrote: > For "small" files I would not worry, the [sanselan] test data > directory is >80MB and no one is complaining. Really? My DSL provider still cannot offer me more than 3MBit/s and this is close to the city center in a town > 250k citizens in Germany, I could im

[general] mvn Release and EU Mirror Lags

Hi, I just did a mvn release:prepare for Compress and it failed in the tagging stage. Since I live in Germany I access our EU svn mirror and the revision that I had created for the non-SNAPSHOT POM had not been replicated back to the mirror so it failed with "no such revision". This is something

[VOTE] Release Commons Compress 1.2 Based on 1.2RC1

Tag: https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.2_RC1/ Site: http://people.apache.org/~bodewig/commons-compress-1.2RC1/site/ Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecommons-004/org/apache/commons/commons-compress/1.2/ Tarballs

Re: [general] mvn Release and EU Mirror Lags

On 2011-07-27, Konstantin Kolinko wrote: > 2011/7/27 Stefan Bodewig : >> Hi, >> I just did a mvn release:prepare for Compress and it failed in the >> tagging stage. >> Since I live in Germany I access our EU svn mirror and the revision that >> I had created for

Re: [compress] Where to Place Big Test Archives?

On 2011-07-26, Ted Dunning wrote: > On Tue, Jul 26, 2011 at 5:31 AM, Stefan Bodewig wrote: >>> Perhaps the large test files could be generated on the fly if absent >>> in the user's temp directory? >> This would require 5 GB of disk space in temp and a working Z

Re: [compress] Where to Place Big Test Archives?

On 2011-07-27, Jörg Schaible wrote: > Different approach: Create out of them separate Maven artifacts. This probably is what I had in mind when I suggested to move them - along with the testcases - somewhere outside of trunk. I just didn't know the proper nomenclature and likely don't know how t

[VOTE][Cancelled] Release Commons Compress 1.2 Based on 1.2RC1

On 2011-07-27, sebb wrote: > On 27 July 2011 06:03, Stefan Bodewig wrote: >> Tarballs/ZIPs: >> http://people.apache.org/~bodewig/commons-compress-1.2RC1/ >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [X] -1 no, do not release it because >

Re: [compress] Where to Place Big Test Archives?

On 2011-07-27, Torsten Curdt wrote: > But to be clear: this is quite some work just to safe some disk space > for people who check out the whole of commons but do not care about > compress. Actually my main concern was/is the size of the source distribution and network bandwidth rather than disk

[VOTE] Release Commons Compress 1.2 Based on 1.2RC2

Tag: https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.2_RC2/ Site: http://people.apache.org/~bodewig/commons-compress-1.2RC2/site/ Tarballs/ZIPs: http://people.apache.org/~bodewig/commons-compress-1.2RC2/ Maven artifacts: https://repository.apache.org/content/reposito

[compress] Staging Site in src/site (was Re: [VOTE] Release Commons Compress 1.2 Based on 1.2RC1)

On 2011-07-27, sebb wrote: > Aside: > Seems wrong that site plugin creates output under src/site - surely it > should be created under target? > Is there a bug in the POM or the Commons Parent POM - or is it a bug > in the site plugin? Apart from the obvious fact that I don't know what I do when

[compress] Creating Distribution Tarballs

Hi all, at least for Compress "mvn -Prc package" (or any variation I have tried) does not create the tarballs/zips and for the last two RCs I've created them manually with assembly:single and a bash one-liner to create the checksums/PGP sigs. Am I doing anything wrong or is there anything wrong i

Re: [compress] Where to Place Big Test Archives?

On 2011-07-27, Gary Gregory wrote: > The best workaround I can see is to create a separate download for the > test data. This allows developers who need sources for debugging to > still get them without downloading GBs of test data. I agree and - to the extent that I understand it - Jörg's sugges

[compress] ZIP64 Progress

Hi, the current version of the zip64 branch is at least able to correctly uncompress the 5GB file that is contained inside my InfoZIP generated zip archive. If anybody wants to give it an early try against archives created by one of the many other implementations, that would be great. Right now

Re: [compress] Creating Distribution Tarballs

On 2011-07-28, Phil Steitz wrote: > On 7/27/11 9:56 PM, Stefan Bodewig wrote: >> at least for Compress "mvn -Prc package" (or any variation I have tried) >> does not create the tarballs/zips and for the last two RCs I've created >> them manually with ass

Re: [VOTE] Release Commons Compress 1.2 Based on 1.2RC2

On 2011-07-29, Phil Steitz wrote: > I had to hack the pom to get it to work under jdk 1.4 (remove > assembly plugin, back rev surefire to 2.0) with maven 2.0.10; but > all code and tests compile and succeed for the jdks above. Given > that the maven build will not work for jdk 1.4, it might have

Re: [VOTE] Release Commons Compress 1.2 Based on 1.2RC2

On 2011-07-28, Oliver Heger wrote: > Minor nit: The RAT report on the site contains a bunch of files which > should not probably be there. When I build the site locally, it looks > cleaner. This - again - seems to be because I ran the site:stage-deploy with stagingDirectory set to src/site as the

Re: [VOTE] Release Commons Compress 1.2 Based on 1.2RC2

just realized I haven't voted myself, yet. On 2011-07-28, Stefan Bodewig wrote: > Tag: > https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.2_RC2/ > Site: > http://people.apache.org/~bodewig/commons-compress-1.2RC2/site/ > Tarballs/ZIPs: > h

[RESULT][VOTE] Release Commons Compress 1.2 Based on 1.2RC2

Hi all, a bit more than 72 hours later and the vote has passed with binding +1s from Oliver Heger Phil Steitz Torsten Curdt Christian Grobmeier Gary Gregory Jörg Schaible Stefan Bodewig and no other votes. I'll now copy the distribution files over to the dist area and promote the Nexus st

Re: [RESULT][VOTE] Release Commons Compress 1.2 Based on 1.2RC2

On 2011-07-31, Stefan Bodewig wrote: > wait for the mirrors to catch up and after that (likely not before > tomorrow) publish the new site which will be a copy of <http://people.apache.org/~bodewig/commons-compress/site/

[compress] ZIP64 Branch Merged to trunk

Hi, after the 1.2 release is out I've merged back the ZIP64 branch, which means compress' trunk now requires Java5. Before I merged the branch I created a new one from trunk in case we ever want to create a Java 1.4 compatible 1.2.1 release. The current status of ZIP64 support is: * ZipArchiveI

[ANNOUNCE] Apache Commons Compress 1.2 Released

e the Apache Commons Compress website: http://commons.apache.org/compress/ Stefan Bodewig, on behalf of the Apache Commons community - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [GUMP@vmgump]: Project jakarta-turbine-jcs (in module apache-commons) failed

On 2011-08-01, Gump wrote: > [javac] Compiling 265 source files to > /srv/gump/public/workspace/apache-commons/jcs/build > [javac] > /srv/gump/public/workspace/apache-commons/jcs/src/java/org/apache/jcs/admin/servlet/JCSAdminServlet.java:30: > package org.apache.velocity.tools.view does

<    1   2   3   4   5   6   7   8   9   10   >