literate-api brings in its own version of Guava

[Kohsuke Kawaguchi]

Mostly to Stephen,

I noticed that this library depends on a version of Guava, but when you run inside Jenkins you end up loading Guava from Jenkins core.

This can lead to a problem at runtime that tests wouldn't catch, so you might want to revisit this. Just FYI.

--
Kohsuke Kawaguchi

[Stephen Connolly]

good catch... you know how I hate guava's asm-like treatment of api compat... I will sort it out tomorrow

--
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-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jesse Glick]

On Wed, Oct 16, 2013 at 8:06 PM, Stephen Connolly
<stephen.al...@gmail.com> 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.

[Stephen Connolly]

Well literate-api wasn't even using guava... It was a left over dependency from some experiments... I agree that we need a better story but it might be a story than needs Jenkins 2.0 to enact

--
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-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Sent from my phone