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.

Reply via email to