On Fri, 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. > It is critical to understand the difference between shading vs. depending. In "depending", Text expects Lang to be on the classpath, and this is enforced at build time by Maven and your POM such that tests can run. In shading (with the Maven shade plugin for example), the build _copies_ the class files from a third party jar into _your_ jar file. Whether you keep the original package names or repackage the third party code is your choice. Gary > > 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 >> >>
