Maven 重新打包传递依赖答案

【问题标题】：Maven repackage transitive dependenciesMaven 重新打包传递依赖
【发布时间】：2018-11-07 10:54:40
【问题描述】：

该应用程序由模块组成，每个模块都是具有一个父级的特定 maven 项目。这些模块在主应用程序中用作 jars。每个模块通过 maven 使用第三方 SDK。这些 SDK 具有许多依赖项，这些依赖项可以具有相同的组和工件，但具有不同的版本。很难管理它们，并且我们遇到了“NoSuchMethodError”的问题。对我来说，解决问题的最简单方法是获取有问题的依赖项的来源和 SDK 的来源，更改包（添加一些前缀）并导入并将其放入 sdk jar 中。但是这种方法需要：一个用于分叉 SDK jar 的 git 存储库和用于发布它们的私有 maven 存储库以及大量时间。是否有 maven 插件可以帮助解决这个问题，例如可以构建包含所有依赖项的 jar（我们的模块 jar）但可以更改所有依赖项的包的插件？

【问题讨论】：

标签： java maven maven-3 maven-plugin maven-assembly-plugin

【解决方案1】：

您可以尝试使用 Maven shade 插件，它允许您重新定位类

https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

但我自己从未尝试过。

在大多数情况下，最好尝试对齐依赖关系，以便在大多数地方使用相同的版本，并将依赖关系减少到最低限度。

【讨论】：

【解决方案2】：

恭喜，您遇到了一个名为“jar hell”的类路径问题。我知道的唯一安全工作的解决方案是为同一类的每个版本使用不同的类加载器（如果它不向后兼容）。

类由其限定名称（包和类名）和已加载的类加载器标识。如果应用程序使用默认的系统类加载器，并且类路径中有不同版本的相同类，则类加载器只会加载一个版本。在 oracle JDK/JRE 中，它首先出现在类路径中。如果幸运的话，您可以按照应用程序运行的特殊顺序引入类路径（顺序并排除依赖项），但我不推荐它，因为它严重依赖 JDK/JRE 实现。

OSGI 是一种可能对此有所帮助的技术，因为它提供了一个基于模块的框架来使用不同的类加载器。

【讨论】：