I have no idea what you are talking about and how your answer concerning "non-relocating options" is relevant to my question about the opposite. I also did not report any surprises during my deployments or runtime behaviour of relocated classes. Thanks for your feedback anyway. Next time, maybe try to contribute a constructive answer instead of a destructive comment, or refrain from replying at all. I would be much obliged. The way you replied sounds just enigmatic at best, lecturing trying to make me feel stupid otherwise. Not helpful!
> You might want to examine the "horrible" Non relocating options > previously outlined if you want a fast resolution to unsurprising > deployments. > > > On Sun, May 16, 2021, 10:41 AM Alexander Kriegisch wrote: > >> When running Maven Shade with relocation, it works nicely. When >> comparing JARs before and after relocation, I was surprised to see >> that Shade not just modifies the relocated classes and classes >> referencing them, but also a bunch of IMO completely unrelated >> classes. In my case I am transforming an uber JAR containing ASM, and >> I selectively relocate the ASM classes, intending to leave all others >> untouched. I know that ASM classes are referred to by some of the >> other classes, but by no means as many as are being modified. The >> byte code is slightly different, probably still does the same thing, >> but it makes comparisons and sanity checks or automatic verification >> steps harder than necessary. BTW, the same Shade execution also >> relocates the sources and really only changes source files >> referencing ASM, just like I would have expected. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
