> On Jul 24, 2020, at 12:00 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> On Fri, Jul 24, 2020 at 11:43 AM Rob Tompkins <chtom...@gmail.com> wrote:
>
>>
>>
>>> On Jul 24, 2020, at 11:36 AM, Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>>>
>>> On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins <chtom...@gmail.com>
>> wrote:
>>>
>>>>
>>>>
>>>>> On Jul 24, 2020, at 9:41 AM, Torsten Curdt <tcu...@vafer.org> wrote:
>>>>>
>>>>>>
>>>>>> You can imagine all manner of jar-hell created by shading. For
>>>> instance:
>>>>>>
>>>>> - library L1 shades library ShadedA-1.0 and ShadedB-1.1.
>>>>>> - library L2 shades library ShadedA-1.1 and ShadedB-1.0.
>>>>>> - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it
>> can't
>>>> no
>>>>>> matter what classpath ordering it uses.
>>>>>> - An app wants to use L1, L2, ShadedA-1.0, and ShadedB-1.0 but it
>> can't
>>>> no
>>>>>> matter what classpath ordering it uses.
>>>>
>>>> I agree here. Shading is quite subtle indeed and can cause Jar hell. I
>> see
>>>> what you’re saying. Hm…this does indeed become interesting.
>>>>
>>>> I suppose we need to have a standard pattern for shading when to, when
>> not
>>>> to, etc. so that we can more effectively have dependency upgrade
>>>> automation??
>>>>
>>>> That said, the point that you make is indeed subtle enough that unless
>> we
>>>> are very simplistic with our shading, dependency upversioning and
>>>> compatibility can
>>>> become an NP-complete problem. Thus we need standards here.
>>>>
>>>
>>> My standard is simple: Don't shade if you offer a jar for reuse.
>>>
>>> Anything offered as a FOSS jar as the potential for reuse and therefore
>>> becomes a potential contributor to shade hell.
>>
>> Sounds like a good place to start. Don’t we shade lang into text though
>> (could totally be wrong here)?
>>
>
> Text does not shade lang. Commons, as far as I know, does not shade
> anything, and IMO should not.
>
Good! I wholeheartedly agree, and this get’s us out of this discussion I
believe. Our consumers may deal with shading as they see fit. But, staying up
to date
on dependencies in an automated fashion is invaluable. I think this is the way
we prevent security vulnerabilities cropping up.
-Rob
> Gary
>
>
>>
>> -Rob
>>
>>>
>>> Gary
>>>
>>>
>>>> -Rob
>>>>
>>>>>>
>>>>>
>>>>> Sorry, but I cannot follow the problems you are trying to show.
>>>>>
>>>>> L1 has ShadeA and ShadeB
>>>>> L2 has ShadeA and ShadeB
>>>>> but both have their own version that doesn't clash and that doesn't
>> know
>>>>> anything about the other one.
>>>>> The app does not see ShadeA or ShadeB from L1 or L2 (unless it uses the
>>>>> hidden package from L1 which would be stupid)
>>>>> There are no clashes and every library uses the version that it needs.
>>>>>
>>>>> To be more explicit. I am maintaining org.vafer.jdependency which uses
>>>>> org.objectweb.asm.
>>>>> If you look at the final jar you find
>>>>>
>>>>> org/vafer/jdeb/shaded/objectweb/asm/*.class
>>>>>
>>>>> The shaded classes are relocated and become part of the context of the
>>>>> library that is shading.
>>>>> A shading hell is just not possible as long as there are no classpath
>>>>> problems on the library itself.
>>>>>
>>>>> It's like you are copy&pasting the code into your package.
>>>>> Bytecode manipulation is really not that bad as you make it to be.
>>>>>
>>>>> Just creating uberjars (without relocation) - that's a whole different
>>>>> story.
>>>>> That should only ever been done on the final application artifact.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
