Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
From: Stefan Bodewig <bodewig@apache.org>
To: dev@commons.apache.org
Subject: Re: [compress] How to move forward with XZ support
References: <87y5yzroli.fsf@v35516.1blu.de>
	<CAOGo0Vb7gkTVekUW2mBibcS7AMNCsz_WE8aG-9LPSZKLLMyF0A@mail.gmail.com>
Date: Fri, 12 Aug 2011 12:59:24 +0200
In-Reply-To: 
 <CAOGo0Vb7gkTVekUW2mBibcS7AMNCsz_WE8aG-9LPSZKLLMyF0A@mail.gmail.com>
	(sebb's message of "Fri, 12 Aug 2011 11:25:59 +0100")
Message-ID: <877h6iq4j7.fsf@v35516.1blu.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 2011-08-12, sebb wrote:

> On 12 August 2011 10:00, Stefan Bodewig <bodewig@apache.org> wrote:

>> We basically have two options:

>> * forking the required classes of "XZ in Java" into Compress (Lasse
>> =C2=A0already has a CLA on file and I'm sure we could arrange for the two
>> =C2=A0code bases to stay in sync)

>> * add a (optional) binary dependency on "XZ in Java". =C2=A0Currently the
>> =C2=A0package is not available via a Maven repo, but this can probably be
>> =C2=A0arranged 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