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