commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [compress] XZ support
Date Tue, 25 Oct 2011 15:53:43 GMT
On 25 October 2011 16:41, Stefan Bodewig <bodewig@apache.org> wrote:
> On 2011-10-25, sebb wrote:
>
>> On 25 October 2011 09:50, Torsten Curdt <tcurdt@vafer.org> wrote:
>>>>> So I would only release the shaded jar.
>
>>>> IIRC sebb objected to shading.
>
>>> Why was that, sebb?
>
>> I don't recall saying that I objected; I did wonder what advantage it
>> would give.
>
> Probably I read more into that question back then than you intended,
> sorry.
>
>>> I cannot think of a good reason why this should be a problem.
>
>> Maybe not in this case, but if the dependency is then updated AIUI
>> using shading would prevent the user from updating the dependency
>> independently.
>
> This is my understanding as well.  I've also been told packagers - those
> people that create RPMs or debs or ... - don't like shaded dependencies
> for the same reason.
>
>>>>  We have the choice of releasing only a
>>>> shaded jar, only a plain jar with a POM that states a hard-dependency
>>>> or releasing two artifacts.
>
>>> You know my preference :)
>
>> Now that XZ is in Maven, it seems to me the simplest solution is to
>> have a dependency on it.
>
> That would be easiest but at the same time force an additional
> dependency for people who don't use XZ at all.  One they could
> explicitly exclude in their POM or ivy.xml or whatever, of course.

Can the dependency be made optional at run-time?

It's simpler to build if the dependency is required at compile time,
but it may not be all that difficult to add the necessary catches to
allow for the dependency to be missing at run time.

> Personally I'm on the fence.
>
> From the POV of the Compress Antlib for example I now need to tell
> people to fetch Common Compress and in the future Id have to tell them
> to fetch XZ as well.  Then again this is a problem I should solve over
> there.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message