Fast forward a little over a year and removing ASM from core in favor
of dynamic linking through a library plugin seems more achievable,
though still quite a bit of work. The following plan seems achievable:

- Create a new ASM library plugin. It would be unused as long as core
keeps shipping ASM, since core's copy would take precedence.
- Make the JNR POSIX library plugin depend on the ASM library plugin.
- Make the JSON Path library plugin depend on the ASM library plugin.
- Make anything that consumes ASM directly depend on the ASM library
plugin (using usage-in-plugins to find all the things).
- Make anything that currently ships the JARs mentioned above depend
on the corresponding library plugin instead (using usage-in-plugins to
find all the things).
- Remove ASM from core.

This is probably a dozen or so PRs to cover plugins with over 10,000
installations, and maybe another dozen or so PRs to cover plugins with
over 1,000 installations, if anyone is interested.

On Mon, Aug 22, 2022 at 7:22 PM Basil Crow <m...@basilcrow.com> wrote:
>
> I think detaching is riskier than I expected: a lot of plugins bundle
> old copies of ASM (or depend on other plugins that do). With core's
> copy no longer taking precedence, I fear that there might be a high
> risk of regression with a detached plugin. Seems safer to deal with
> each plugin on a case-by-case basis.
>
> I searched for usages of ASM (both direct and transitive) in both
> open-source and proprietary plugins. After filtering out plugins that
> bundled a recent (9.x) ASM JAR in their JPI, plugins whose only usage
> of ASM was through Commons Compress Pack200 support (probably not
> used), plugins with fewer than 1,000 installations, and plugins that
> have already been deprecated, I came up with the following list:
>
> https://plugins.jenkins.io/analysis-model-api - via cglib (via Commons
> Digester) and com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/checkmarx - via xbean-reflect-3.7.jar
> https://plugins.jenkins.io/clearcase - via cglib (via Commons Digester)
> https://plugins.jenkins.io/clover - via cglib (via Commons Digester)
> https://plugins.jenkins.io/cvs - via cglib (via Commons Digester)
> https://plugins.jenkins.io/dependency-check-jenkins-plugin - via cglib
> (via Commons Digester)
> https://plugins.jenkins.io/deploy - via
> org.glassfish.main.deployment:deployment-common
> https://plugins.jenkins.io/git-changelog - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/github-autostatus - via JNR
> https://plugins.jenkins.io/github-pr-coverage-status - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/hp-application-automation-tools-plugin -
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/jacoco - directly
> https://plugins.jenkins.io/jnr-posix-api - via JNR
> https://plugins.jenkins.io/kubernetes-pipeline-devops-steps - via JNR
> https://plugins.jenkins.io/maven-dependency-update-trigger - via Plexus
> https://plugins.jenkins.io/maven-info - via cglib (via Commons Digester)
> https://plugins.jenkins.io/multibranch-scan-webhook-trigger -
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/pipeline-model-definition - directly
> https://plugins.jenkins.io/scm-api - directly
> https://plugins.jenkins.io/synopsys-coverity - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/teamconcert - via cglib (via Commons Digester)
> https://plugins.jenkins.io/token-macro - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/warnings-ng - via
> com.jayway.jsonpath/net.minidev:json-smart
>
> These could all be dealt with, but dealing with the long tail
> (anything less than a few thousand installations) would be a huge
> amount of work. If we expect someone to do that work for all the
> plugins listed above, then count me out because the expected value is
> just not worth the effort. If, on the other hand, we would be OK with
> leaving behind a substantial number of the above plugins (especially
> those that have only a few thousand installations and/or have not been
> released in years), then I think this could be doable.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrLMjtskWOeh0ptBeDjoUa41j0WAAqqoQ34yb5DwHg_-Q%40mail.gmail.com.

Reply via email to