commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [compress] Planning for a 1.3 Release?
Date Tue, 11 Oct 2011 15:21:43 GMT
On 2011-10-11, Gary Gregory wrote:

> On Tue, Oct 11, 2011 at 10:20 AM, Stefan Bodewig <> wrote:

>> Hi all,

>> its been quite some time since I finished the Zip64 stuff and I think we
>> are at the point we discussed three month ago or so: release Compress
>> 1.3 even if it doesn't have many big changes when compared to 1.2.  In
>> addition to Zip64 we have read-only support for Unix dump and also
>> Pack200 "compression".  Documentation is fairly complete IMHO.

>> One thing that we may or may not want to address are the integration
>> tests for Zip64 which are currently only run when the run-it profile is
>> enabled.  These tests need some zips generated by other tools that are
>> currently not part of svn and we discussed publishing them as separate
>> artifacts - personally I wouldn't even know where to start for this.

>> Then we do have some JIRAs with patches in particular one for XZ
>> compression and patches for compressors where a single container stream
>> contains multiple compressed streams (I didn't know gzip and bzip2 could
>> do that, I must admit), all by Lasse Collin.

>> The XZ patch has the "problem" that it introduces a new dependency - do
>> we want that or would we prefer a separate module?  In addition XZ for
>> Java is not available via any Maven repo, yet, this may require some
>> tweaking during build time (Ant <get> task?).  Shall we defer this until
>> after the 1.3 release?

> Yes, release early, release often.

> I am not in favor of code all over the place, it should all be in the
> project, whether or not or when it is run is a different story.

> If these are data/resource files, why not put them in a resource jar in MC?

Are you talking about the zips needed for the ZIP64 tests?  I should
have been clearer.  Those zips have been generated by myself using
InfoZIP, WinZip and so on and all have the same contents (albeit all are
slightly different).

By "put them in a resource jar in MC" you mean I'd assemble a single jar
file commons-compress-testresources-1.0.jar that contains all those zips
and publish it, right?

> If something is not in MC, you can always ask to have it put there. The
> issue is that you might have to edit the POM and rebuild the software if the
> POM does not adhere to Apache/MC standards.

In this case I'd have to write the POM myself anyway.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message