> On 10. Apr 2019, at 22:55, Jesse Glick <[email protected]> wrote:
>
> 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.
https://issues.jenkins-ci.org/browse/JENKINS-30685
> 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.
https://issues.jenkins-ci.org/browse/JENKINS-41827
--
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/55F43228-C285-4377-B4B9-DC9BD27565A7%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
