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