Le ven. 24 juil. 2020 à 17:39, Gary Gregory <garydgreg...@gmail.com> a écrit : > > 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.
A shaded class is not part of the public API; how does it affect reuse? I also don't understand your expectation in the Jacoco example: Why should it support more recent class files than those for which that particular version was released? Assuming that Jacoco did not shade that library, perhaps some things would still work with another version of it, while other things would break (I think this was the scenario pointed out by Stefan). > Anything offered as a FOSS jar as the potential for reuse and therefore > becomes a potential contributor to shade hell. I'd also favour explicit dependency over shading. The possibility was presented as an alternative to the "coding horrors" that arise in Commons because of the "no dependency" argument. Gilles > > Gary > > >> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
