On Wed 10 Apr 2019 at 21:55, Jesse Glick <jgl...@cloudbees.com> wrote:
> On Wed, Apr 10, 2019 at 10:48 AM Matt Sicker <msic...@cloudbees.com> > 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 jenkinsci-dev+unsubscr...@googlegroups.com. > 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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
