What's the current story with guava? I.E: if you're pluginFirstClassLoader and a later-than-core guava in WEB-INF/lib, will this work? Or are you saying this implementation will 'leak' into other plugins?
I notice jclouds-plugin goes to lengths to shade its dependency. It'd be nice if the jenkins plugin manager could do that (the shading) at deploy-time.. On Fri, Feb 6, 2015 at 1:42 PM, Jesse Glick <[email protected]> wrote: > On Fri, Feb 6, 2015 at 7:08 AM, Kirill <[email protected]> wrote: > > So you actually say that plugins share their libraries unless the > > child-first classloading is defined? > > No, I think several possible cases are being mixed up in this discussion. > > If the library is bundled in Jenkins core, you have a problem, because > the sloppy design here lets every plugin “see” libraries used by core, > even if it only intended to use them internally (rather than > reëxporting some of their types). To use a different version of the > library from your plugin, you need to (a) declare a dependency on it > from your POM, ensuring it is bundled in WEB-INF/lib/*.jar, (b) select > plugin-first class loading mode for this plugin (a dangerous option > disabled by default). > > If the library is just something your plugins bundle that core does > not, and neither plugin depends on the other, normally you are fine. > The potential problems: > > · Some Jelly view etc. tries to load a resource such as an icon by > package path; one version or the other is chosen arbitrarily. Maybe > OK. > · The author of the library (Xerces…) was a raving madman and defined > some extension points with default implementations which are loaded by > the equivalent of calling > > Thread.currentThread().getContextClassLoader().loadClass("the.known.default.impl.which.is.actually.in.the.same.JAR"). > You will get mysterious ClassCastException’s. The workaround is to > wrap any call to the library from your plugin in a try-finally block > which sets the CCL to the ClassLoader of some class in the plugin or > its bundled library. > > If one or the other plugin depends on the other, or some third plugin > needs to depend on both, then the only option is to align versions of > the library. Merely picking the same version in each plugin is *not* > enough; you will still get linkage errors, because the same bytecode > will be loaded twice. You need to factor out the library into its own > otherwise empty plugin, and declare a regular plugin dependency on it. > > > If they'd share their libs, every Jenkins instance would be a "JAR hell" > - but it's not. > > Well, most Jenkins instances are not JAR hells. But some are. > > -- > 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/CANfRfr107f2%2Bb2YSM_kWUk25wObzz3Yc3Q7kORX7fy%3DN0bmDBw%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/CAPYP83R9iVJe_crE%3D3Q9xTKUZT5j4C8wugkzJDGV3Jtdka7jbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
