On Wed, Oct 16, 2013 at 8:06 PM, Stephen Connolly <[email protected]> wrote: > I will sort it out tomorrow
We have run into this sort of problem in the past with ASM and BouncyCastle at least. Generally speaking, Jenkins core violates a basic principle of API design: it should never expose to plugins the existence of libraries Jenkins uses only internally (i.e. which do not contribute types to its own public signatures). In OSGi, for example, this distinction is made clear. What should our general policy be, for existing dependencies of jenkins.jar as well as new ones? Options I can think of: · Leave core untouched and ask plugins to use pluginFirstClassLoader/maskClasses on an as-needed basis. · Shade new libraries in core into a version-specific package so plugins would not accidentally see them. Cannot compatibly be done for existing libraries, unless that version of the library is additionally packaged into a bundled plugin which is listed in ClassicPluginStrategy.DETACHED_LIST (and this can only work for libraries which do not keep important static state). · Add an implicit Global-Mask-Classes for all jenkins.jar dependencies not specifically exempted. Has the same compatibility implications as the second option. -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
