Drop ASM; use already present one

[cstamas]

Given jdependency is a key dependency of this plugin, and it already have full ASM shaded in, why not use it?

See
tcurdt/jdependency#389

THIS IS JUST EXPERIMENT and pro-con discussion starter

[elharo]

I don't know that we can rely on this being present. And has it been changed in any way?

[cstamas]

Yes, it was "moved" (namespace-wise) by this very same plugin in https://github.com/tcurdt/jdependency build. But semantic wise there should be no alteration, if am right.

[olamy]

Well TBH I would not do it.
With almost every new jdk version users of shade plugin need an update of ASM.
When this happen, users can simply add the version of ASM in shade plugin dependencies and it works and very simple
Now this will add an hard dependency to an external library to cut a release with a new shaded version of ASM.
Personnal case, on the Jetty project we often test new jdk version as soon as we can and we always need to do this. With such changes, we will not be able to do this and for something minimizeJar which is an optional option

[cstamas]

I agree, but as explained on PR comment; jdependency is already a key dependency of this plugin (unsure what you mean by "hard dependency"). But yes, I agree with sentiment, also look at linked issue: tcurdt/jdependency#389

[elharo]

But we can't rely on the shaded version of asm in jdependency being up to date with what we need. If we depend on asm directly, and we do, we should depend on it directly.

[cstamas]

See comment above yours: jdependency author is (and always was) tracking and releasing his own project whenever new ASM went out.

But yes, this PR is just meant as "food for thought" and not to be merged, as I do agree with all responses.

[cstamas]

I agree with comments on this PR, this is not right thing to do.
Personally, I am on same stance as with SNAPSHOTS: we could consume asm like this IF we govern the downstream project (see "one should not consume 'foreign' snapshots").