简体繁体 English

Maven 重新打包传递依赖

[英]Maven repackage transitive dependencies

原文 2018-11-07 10:54:40 8 2 java/ maven/ maven-3/ maven-plugin/ maven-assembly-plugin

The app consists of modules and each module is particular maven project with one parent.该应用程序由模块组成，每个模块都是具有一个父级的特定 maven 项目。 These modules are used as jars in main app.这些模块在主应用程序中用作 jar。 Each module uses third party SDK via maven.每个模块通过 maven 使用第三方 SDK。 These SDKs have many dependencies and these dependencies can be with the same group and artifact but with different versions.这些 SDK 有许多依赖项，这些依赖项可以具有相同的组和工件，但具有不同的版本。 It is hard to manage them and we have problems with 'NoSuchMethodError's.很难管理它们，而且我们遇到了“NoSuchMethodError”的问题。 As for me the simplest way to fix problem is to get sources of problematic dependencies and source of SDK, change the package (add some prefix) and imports and put it inside sdk jar.对我来说，解决问题的最简单方法是获取有问题的依赖项的来源和 SDK 的来源，更改包（添加一些前缀）并导入并将其放入 sdk jar 中。 But this approach requires: one more git repository for forked SDK's jars and private maven repository to publish them and a lot of time.但是这种方法需要：另外一个用于分叉 SDK 的 jar 的 git 存储库和用于发布它们的私有 Maven 存储库以及大量时间。 Is there maven plugin that can help with this problem, for example plugin that can build jar (our module jar) with all dependencies included inside it but can change package of all dependencies?是否有 maven 插件可以帮助解决这个问题，例如可以构建包含所有依赖项的 jar（我们的模块 jar）但可以更改所有依赖项的包的插件？

2 个解决方案

You can try to use the Maven shade plugin which allows you to relocate classes您可以尝试使用 Maven shade 插件，它允许您重新定位类

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

but I have never tried this myself.但我自己从未尝试过。

In most cases it is better to try to align the dependencies so that you use the same versions in most places and also to reduce dependencies to a minimum.在大多数情况下，最好尝试对齐依赖项，以便在大多数地方使用相同的版本，并将依赖项减少到最低限度。

Congratulations, you are confronted with a classpath problem called "jar hell".恭喜，您遇到了一个称为“jar 地狱”的类路径问题。 The only safely working solution i know is the use of different classloaders for each version of the same class (if it's not backward compatible).我知道的唯一安全工作的解决方案是为同一类的每个版本使用不同的类加载器（如果它不向后兼容）。

A class is identified by its qualified name (package and class name) and by the classloader it has been loaded.一个类由它的限定名（包和类名）和它被加载的类加载器标识。 If the application uses the default system classloader and there is the same class in different versions in the classpath only one version will be loaded by the classloader.如果应用程序使用默认的系统类加载器，并且类路径中存在不同版本的相同类，则类加载器只会加载一个版本。 In the oracle JDK/JRE it is the one which occurred first in the classpath.在 oracle JDK/JRE 中，它是第一个出现在类路径中的。 If you are lucky you can bring the classpath (order and excluding dependencies) in a special order in which your application will run, but i wouldn't recommend it since it relies heavy on the JDK/JRE implementation.如果幸运的话，您可以按照应用程序运行的特殊顺序引入类路径（顺序和排除依赖项），但我不建议这样做，因为它严重依赖于 JDK/JRE 实现。

OSGI is a technology which might be helpful for this since it provides a module based framework for using different classloaders. OSGI 是一种可能对此有所帮助的技术，因为它提供了一个基于模块的框架来使用不同的类加载器。