On Wed, Apr 10, 2019 at 6:44 PM Stephen Connolly
wrote:
> If the “classboxed” dependencies have scope=provided then they shouldn’t be
> transitive and you could leave them unshaded.
True. `war/pom.xml` would need to be massaged to bundle them.
> The JenkinsRule would just need to setup the
On Thu, Apr 11, 2019 at 4:10 AM Ullrich Hafner wrote:
> [shading does not] prevent developers to use the shaded classes, they are
> still there, just with another package name
True, but the Jenkins plugin class loader can refuse to serve such
classes, so any such mistake would immediately fail
On Wed 10 Apr 2019 at 21:55, Jesse Glick wrote:
> On Wed, Apr 10, 2019 at 10:48 AM Matt Sicker
> 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
> On 10. Apr 2019, at 22:55, Jesse Glick 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.
I've been struggling for a while now on how to best approach
dependency management in Jenkins. One of our key pain points has been
in shared libraries like Jackson, HttpComponents, AsyncHTTPClient, and
various other commonly used libraries. As we've already found, simply
including these common
