> On 10. Apr 2019, at 22:55, Jesse Glick <jgl...@cloudbees.com> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.
