> 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.
-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
