> Am 10.04.2019 um 22:55 schrieb Jesse Glick <[email protected]>: > > 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. >
As far as I understand shading it does not prevent developers to use the shaded classes, they are still there, just with another package name. And since every IDE has automatic code completion nobody actually looks at the package names anymore. (We can add an architecture test or check style rule to prevent those imports though.) > > 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. Maybe we can use an enforcer rule like https://github.com/Scout24/illegal-transitive-dependency-check <https://github.com/Scout24/illegal-transitive-dependency-check> that checks that no transitive dependencies are used at all? Then developers need to provide explicit dependencies. The only problem I see here is if classes of the dependency are part of the plugin API. Then it is unclear to me which class will be picked by Jenkins class loader. (But as far as I know this problem will occur in OSGi as well) > 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. -- 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/7B0283B5-ABCF-45A5-BACF-B6654A6B1586%40gmail.com. For more options, visit https://groups.google.com/d/optout.
