Maven：包含带有与其他依赖项冲突的捆绑库的第3方jar

Question

I've been looking for the answer to this for a few days and have turned up empty.

I'm devving a Confluence plugin that integrates with a 3rd party app. This 3rd party app has a nice REST API and they even provide a Java SDK (yay!). Except.....the Java SDK has bundled a version of Jersey (1.18) that conflicts with Confluence's forked version of Jersey (1.8-atlassian_15). The SDK was not released as a Maven jar (or at least there's no pom.xml included). There ARE other pom.xml in the jar's META-INF for the dependencies it uses, but the SDK itself is just released as a jar download by the vendor.

So as I've done in the past, I mvn install:install-file the sucker with my own groupId and artifactId, thinking it'd be fine. Intellij recognized the library, everything compiled nicely, and then I tried my test call to the REST API. This is when it threw an error that made it evident that there's a conflict between the versions.

SOOOO. Is there anyway to get around this? Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses? I have a feeling that even after the Jersey dependency is resolved (if that's even possible) there will be other issues....The SDK also bundles the specific version of Jackson, Swagger, etc. with it.

I attempted to decompile the jar and include the decompiled code in my project, but that just had all of issues I'd rather not deal with ever again.

I have reached out the SDK devs to see if they could release a more maven-friendly release, but I'm not hopeful this will be done at all, and even it is, their release cycle is much different than my own requirements (read: I need a solution now). This is my last-ditch effort before rewriting the REST client from scratch.

Answer 1

Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses?

Sure you can. Often-used way to do this is to use Maven shade plugin that transforms an existing jar to a shaded jar , using another package hierarchy and getting rid of the package naming conflict. See also the documentation about relocating packages . I suggest you use that - that's what I've done in cases like this (though I haven't done confluence plugin development, but it should be the same thing as with other platforms).