Stop shading in ASM, or, provide ASM-less JAR

[cstamas]

Like all the libraries that did shade ASM in past stopped doing that. Guice, Sisu, etc all stopped as shading is just source of the problems.

Fx Guice provided "classes" classifier, that is Guice only, w/o ASM classes.

[tcurdt]

I wouldn’t characterize shading per se as "the source of the problems" - it’s a trade-off.
Some projects have moved away from it, while others continue to rely on it for dependency isolation.

In this case, shading has worked reasonably well, and jdependency releases have generally tracked ASM updates with minimal delay.

That said, if there is a genuine need for an unshaded artifact, I’m open to adding a secondary variant.

However, this would need to come as a contribution.

[Goooler]

There are a few benefits to shading ASM; for example, see GradleUp/shadow#1898.

This could be improved by completing #383.

[cstamas]

This means that your dependency, in this case jdependency "drives" the version of used ASM for you. I like it in reverse: jdependency, guice, sisu and many other thing used in Maven Core needs ASM but we, Maven Core are the one who drive (set) the existing ASM version and pull it in as dependency.

If @tcurdt wins the eurojackpot, who will you ask to update ASM version? 😆

[tcurdt]

This means that your dependency, in this case jdependency "drives" the version of used ASM for you. I like it in reverse: jdependency, guice, sisu and many other thing used in Maven Core needs ASM but we, Maven Core are the one who drive (set) the existing ASM version and pull it in as dependency.

It's the classic static vs dynamic dependency discussion.

IMO dynamic dependency resolution is the road paved to dependency hell. But I know this is a spicy discussion.
I think (as always) this should be seen nuanced. There is not good/bad.

One can argue that ASM is an implementation detail and downstream should not have to care about it.
One can also argue that only that combination of dependencies are tested instead of relying on semantic versioning.

If the release lag is small enough I do prefer the blackbox approach and by that do my contribution to cut down the dependency tree (at least a little).

If you insist on a ASM-less jar. I am OK to accept the contribution. But I am really not a fan. Right now everything is KISS. It would increase the build complexity and I am not sure about the net benefit. It could help to pave the road to #391 though.

The upgrades are mostly automatic (via renovate) anyway.
And if changes are minor I either release right away or hold back for more changes if they are not important.

I think the recent m-shade-p hick-up just brought the min java version problem to light.
It was a slightly different problem.

If @tcurdt wins the eurojackpot, who will you ask to update ASM version? 😆

Then I will have enough free time to help on OSS 🙃
...or at least pass on the maintainer torch - maybe even paid ;-)