我几天来一直在寻找答案，并且空了。
我正在使用与第三方应用集成的Confluence插件。这个第三方应用程序有一个很好的REST API，他们甚至提供Java SDK（耶！）。除了...... Java SDK捆绑了一个版本的Jersey（1.18），它与Confluence的分叉版Jersey（1.8-atlassian_15）相冲突。 SDK没有作为Maven jar发布（或者至少没有包含pom.xml）。 jar的META-INF中还有其他pom.xml用于它所使用的依赖项，但SDK本身只是由供应商发布的jar下载。
正如我过去所做的那样，我mvn install:install-file有我自己的groupId和artifactId的傻逼，认为它没事。 Intellij识别了库，很好地编译了所有内容，然后我尝试了对REST API的测试调用。这是因为它发出错误，表明版本之间存在冲突。
SOOOO。反正有没有绕过这个？我可以＆＃34;沙箱＆＃34; SDK jar以某种方式在自己的交易中执行代码而不暴露于SDK使用的Confluence的内置版本库的恶意软件？我有一种感觉，即使在Jersey依赖性得到解决后（如果可能的话）也会有其他问题...... SDK还会将Jackson，Swagger等特定版本捆绑在一起。
我试图反编译jar并在我的项目中包含反编译的代码，但这只是我不想再处理的所有问题。
我已经联系了SDK开发人员，看看他们是否可以发布一个更加友好的版本，但我并不希望这将会完成，即便如此，他们的发布周期也不同于我自己的要求（读：我现在需要一个解决方案）。在从头开始重写REST客户端之前，这是我最后的努力。
答案 0 :(得分：0)
我能否以一种在自己的交易中执行代码的方式“沙盒化”SDK jar，而不会暴露给SDK使用的Confluence内置版本库的恶意内容？
当然可以。经常使用的方法是使用Maven shade plugin将现有jar转换为着色jar ，使用另一个包层次结构并消除包命名冲突。另请参阅有关relocating packages的文档。我建议你使用它 - 这就是我在这样的情况下所做的事情（尽管我还没有完成融合插件的开发，但它应该和其他平台一样）。