On Wed, Apr 10, 2019 at 10:48 AM Matt Sicker <[email protected]> wrote:
> 1. Shade in third party dependencies of Jenkins core into Jenkins with
> a package rename. This will allow core to use the dependencies, but
> plugins will still need to include the dependencies explicitly. This
> could potentially be combined with a compatibility shim for plugins
> that try to load a class that doesn't exist.

You do not necessarily need to rename packages. It suffices for the
plugin class loader defined in Jenkins core to decline to forward
class loading requests for these libraries to the parent. (The
implementation already exists to some extent, in the
`pluginFirstClassLoader` option, but this is too extreme because it
applies to _all_ class loads whereas we only want to decline certain
names.) Combined with the existing detached plugin system for backward
compatibility, you have a complete runtime solution, and rather easily
at that.

The problems are in the developer tooling. `compiler:compile` and
`JenkinsRule` via `surefire:test` are going to pick up transitive
dependencies of `jenkins-core` in a flat classpath. Thus if a plugin
built against a new core baseline (one after the change) _does_
declare an explicit dependency on the new library wrapper plugin,
Maven will pick one or the other version to build & test against
(depending on POM details of where this dependency appears in the tree
relative to `jenkins-core`); if it does _not_, Maven will silently
build & test against the library as bundled in core, even though at
runtime this would be a `NoClassDefFoundError`. These problems make me
think that shading is more practical.

> 4.alt. I don't know enough about JPMS, but perhaps it can be used to
> help enforce something similar?

Last I checked it was much less flexible than what we already have in
Jenkins core, so it would be hard to migrate to. (Requiring Java 11+
would be the least of our worries.)

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr285%2Bc7FnDwmes-H5T04kNX%2BhP5z_8JkY2heHYH_VXhzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to