On Wed 10 Apr 2019 at 21:55, Jesse Glick <[email protected]> wrote:
> 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. If the “classboxed” dependencies have scope=provided then they shouldn’t be transitive and you could leave them unshaded. The JenkinsRule would just need to setup the classloaders from the war and all would be fine > > > > 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. > -- Sent from my phone -- 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/CA%2BnPnMzO%3D3Jxgzs_OaMP6w%3DsLccfZgAYycZbGW03MYepQ4ECoA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
