Overall +1 on not relocating (shading by itself is not a big deal) but we should ensure resources too are properly isolated (not always the case and class only isolation leads to bugs). Not 100% it affects httpclient but as a general rule it sounds like the only missing thing in classrealm.
Le mar. 1 févr. 2022 à 16:21, Tamás Cservenák <[email protected]> a écrit : > Howdy, > > As part of an "experiment" on Maven with transport-http > https://github.com/apache/maven/pull/635 I was wondering why wagon-http > shades http-client, and should resolver transport-http shade as well or > not... I was somehow convinced this is dragged from maven2... (that leaked > into plugins) and we just left things as they were? > > So, decided to try it out, and wrote a little "helper": > https://github.com/cstamas/maven-test-extension > > It may test class visibility from > - core extension (copy the locally built maven-test-extension JAR into > lib/ext) > - build extension (uncomment the part in maven-test-extension AFTER you > built it) > - mojo (invoke it directly or indirectly) > > And with locally built maven-transport-http (PR above, that uses non-shaded > http-client) and maven-test-extension (repo above), the result shows that > - http-client IS visible in core-extension > - http-client IS NOT visible in build-extension > - http-client IS NOT visible in mojo > > IMHO, this is "as expected". > > Hence, IMHO we should stop shading stuff in Maven core, as http-client is > NOT leaking into plugins and build-extensions. Question is core extensions > that DOES see http-client... > > Not shading not just simplifies things, but also makes possible extending > resolver from maven extensions (of those bits that use http-client, like > "smart checksums" feature, so a maven extension could provide a new > component implementing "smart checksums"). > > Any thoughts about this? > > T >
