You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2011/08/12 11:00:41 UTC
[compress] How to move forward with XZ support
Hi,
.xz is to LZMA what .gz is to the DEFLATE compression algorithm, and it
starts to get used by quite a few tools/systems in the Unix/Linux
world. For example more recent GNU tar versions use -J to support the
format (like -z for gzip and -j for bzip2), the GNU core utils come
with an xz command and recent RPMs can use .xz compressed tarballs as
well. This is a format we want to support 8-)
Lasse Collin the author of the public domain "XZ in Java" package[1] has
offered to help us build Compressors on top of his package.
We basically have two options:
* forking the required classes of "XZ in Java" into Compress (Lasse
already has a CLA on file and I'm sure we could arrange for the two
code bases to stay in sync)
* add a (optional) binary dependency on "XZ in Java". Currently the
package is not available via a Maven repo, but this can probably be
arranged as well.
The first option would allow us to support the format without requiring
another JAR, the second one may be less work from a maintenance POV.
Shading a binary dependency could provide some middle ground.
Which option do we prefer?
Stefan
[1] http://tukaani.org/xz/java.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] How to move forward with XZ support
Posted by Torsten Curdt <tc...@vafer.org>.
>> Shading a binary dependency could provide some middle ground.
>
> Just curious - what is the advantage of shading the jar?
It becomes again just one jar with no dependencies ...almost as if we
forked the code.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] How to move forward with XZ support
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-12, sebb wrote:
> On 12 August 2011 10:00, Stefan Bodewig <bo...@apache.org> wrote:
>> We basically have two options:
>> * forking the required classes of "XZ in Java" into Compress (Lasse
>> already has a CLA on file and I'm sure we could arrange for the two
>> code bases to stay in sync)
>> * add a (optional) binary dependency on "XZ in Java". Currently the
>> package is not available via a Maven repo, but this can probably be
>> arranged as well.
>> The first option would allow us to support the format without requiring
>> another JAR, the second one may be less work from a maintenance POV.
> +1
Which one of the two options does your +1 apply to?
I see some advantages in forking the code but lean towards binary
dependency + shading. The code is public domain so there is no problem
with redistributing it as is.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] How to move forward with XZ support
Posted by sebb <se...@gmail.com>.
On 12 August 2011 10:00, Stefan Bodewig <bo...@apache.org> wrote:
> Hi,
>
> .xz is to LZMA what .gz is to the DEFLATE compression algorithm, and it
> starts to get used by quite a few tools/systems in the Unix/Linux
> world. For example more recent GNU tar versions use -J to support the
> format (like -z for gzip and -j for bzip2), the GNU core utils come
> with an xz command and recent RPMs can use .xz compressed tarballs as
> well. This is a format we want to support 8-)
>
> Lasse Collin the author of the public domain "XZ in Java" package[1] has
> offered to help us build Compressors on top of his package.
>
> We basically have two options:
>
> * forking the required classes of "XZ in Java" into Compress (Lasse
> already has a CLA on file and I'm sure we could arrange for the two
> code bases to stay in sync)
>
> * add a (optional) binary dependency on "XZ in Java". Currently the
> package is not available via a Maven repo, but this can probably be
> arranged as well.
>
> The first option would allow us to support the format without requiring
> another JAR, the second one may be less work from a maintenance POV.
+1
> Shading a binary dependency could provide some middle ground.
Just curious - what is the advantage of shading the jar?
> Which option do we prefer?
>
> Stefan
>
> [1] http://tukaani.org/xz/java.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] How to move forward with XZ support
Posted by Torsten Curdt <tc...@vafer.org>.
> We basically have two options:
>
> * forking the required classes of "XZ in Java" into Compress (Lasse
> already has a CLA on file and I'm sure we could arrange for the two
> code bases to stay in sync)
>
> * add a (optional) binary dependency on "XZ in Java". Currently the
> package is not available via a Maven repo, but this can probably be
> arranged as well.
Keeping the sources in sync is too much of a hassle. No need for an
optional binary dependency though.
Let's help him get his releases into central and then use the maven
shade plugin. That way we only have a build time dependency and no
manual syncing work.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] How to move forward with XZ support
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-12, Lasse Collin wrote:
> On 2011-08-12 Stefan Bodewig wrote:
>> the GNU core utils come with an xz command
> Minor correction: GNU coreutils doesn't include compression tools.
> GNU gzip is its own package and so are bzip2 (bzip.org) and xz
> (tukaani.org).
Thank you.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] How to move forward with XZ support
Posted by Lasse Collin <la...@tukaani.org>.
On 2011-08-12 Stefan Bodewig wrote:
> the GNU core utils come with an xz command
Minor correction: GNU coreutils doesn't include compression tools.
GNU gzip is its own package and so are bzip2 (bzip.org) and xz
(tukaani.org).
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org