maven-shade-plugin 的用途是什么，为什么要重新定位 Java 包? [英] What is the maven-shade-plugin used for, and why would you want to relocate Java packages?

问题描述

我发现在某人的 pom.xml 中使用了 maven-shade-plugin.我以前从未使用过 maven-shade-plugin(我是 Maven n00b)所以我试图了解使用它的原因和它的作用.

I found the maven-shade-plugin being used in someone's pom.xml. I've never used maven-shade-plugin before (and I'm a Maven n00b) so I tried to understand the reason for using this and what it does.

我查看了 Maven 文档，但是我无法理解这一点声明:

I looked at the Maven docs, however I can't understand this statement:

此插件提供了将工件打包到 uber-jar 中的功能，包括其依赖项和遮蔽 - 即重命名 - 某些依赖项的包.

This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.

页面上的文档似乎对新手不太友好.

The documentation on the page doesn't seem very newbie-friendly.

什么是超级罐子"?为什么有人想做一个?重命名依赖项的包有什么意义?我尝试浏览 maven-shade-plugin apache 页面上的示例，例如为 Uber Jar 选择内容"，但我仍然无法理解着色"正在完成什么.

What is an "uber jar?" Why would someone want to make one? What's the point of renaming the packages of the dependencies? I tried to go through the examples on the maven-shade-plugin apache page such as "Selecting contents for Uber Jar," but I still can't understand what is being accomplished with "shading."

任何指向说明性示例/用例的指针(解释为什么在这种情况下需要着色 - 它解决了什么问题)将不胜感激.最后，我应该什么时候使用 maven-shade-plugin?

Any pointers to illustrative examples/use-cases (with an explanation of why shading was required in this case - what problem is it solving) would be appreciated. Lastly, when should I use the maven-shade-plugin?

推荐答案

Uber JAR，简而言之，就是一个包含一切的 JAR.

Uber JAR, in short, is a JAR containing everything.

通常在 Maven 中，我们依赖于依赖管理.工件仅包含其自身的类/资源.Maven 将负责根据项目的构建时间找出项目的所有工件(JAR 等).

Normally in Maven, we rely on dependency management. An artifact contains only the classes/resources of itself. Maven will be responsible to find out all artifacts (JARs etc) that the project depending on when the project is built.

一个 uber-jar 是一种获取所有依赖项的东西，并提取依赖项的内容并将它们与项目本身的类/资源放在一个大 JAR 中.通过拥有这样一个 uber-jar，它很容易执行，因为您只需要一个大 JAR 而不是成吨的小 JAR 来运行您的应用程序.在某些情况下，它还可以简化分发.

An uber-jar is something that takes all dependencies, and extracts the content of the dependencies and puts them with the classes/resources of the project itself, in one big JAR. By having such an uber-jar, it is easy for execution, because you will need only one big JAR instead of tons of small JARs to run your app. It also eases distribution in some cases.

顺便说一句:避免使用 uber-jar 作为 Maven 依赖项，因为它会破坏 Maven 的依赖项解析功能.通常我们只为最终的工件创建一个 uber-jar 用于实际部署或手动分发，而不是放入 Maven 存储库.

Just a side-note: avoid using uber-jar as a Maven dependency, as it is ruining the dependency resolution feature of Maven. Normally we create an uber-jar only for the final artifact for actual deployment or for manual distribution, but not for putting to Maven repository.

更新:我刚刚发现我没有回答问题的一部分:重命名依赖项的包有什么意义?".以下是一些简短的更新，希望能帮助有类似问题的人.

Update: I have just discovered I haven't answered one part of the question : "What's the point of renaming the packages of the dependencies?". Here are some brief updates that will hopefully help people having similar questions.

创建一个易于部署的 uber-jar 是 shade 插件的一个用例.还有其他常见用例涉及包重命名.

Creating an uber-jar for ease of deployment is one use case of the shade plugin. There are also other common use cases which involve package renaming.

例如，我正在开发 Foo 库，它依赖于 Bar 库的特定版本(例如 1.0).假设我无法使用其他版本的 Bar lib(因为 API 更改或其他技术问题等).如果我在Maven中简单地将Bar:1.0声明为Foo的依赖，可能会陷入一个问题:一个Qux项目依赖在 Foo 上，还有 Bar:2.0(它不能使用 Bar:1.0 因为 Qux 需要使用 newBar:2.0 中的功能).这是一个难题:应该 Qux 使用 Bar:1.0(Qux 的代码不起作用)还是 Bar:2.0(哪个 Foo 的代码不起作用)?

For example, I am developing Foo library, which depends on a specific version (e.g. 1.0) of Bar library. Assuming I cannot make use of other version of Bar lib (because API change, or other technical issues, etc). If I simply declare Bar:1.0 as Foo's dependency in Maven, it is possible to fall into a problem: A Qux project is depending on Foo, and also Bar:2.0 (and it cannot use Bar:1.0 because Qux needs to use new feature in Bar:2.0). Here is the dilemma: should Qux use Bar:1.0 (which Qux's code will not work) or Bar:2.0 (which Foo's code will not work)?

为了解决这个问题，Foo的开发者可以选择使用shade插件来重命名Bar的用法，使得Bar中的所有类:1.0 jar被嵌入到Foo jar中，嵌入的Bar类的包由com.bar改为com.foo.bar.通过这样做，Qux 可以安全地依赖于 Bar:2.0 因为现在 Foo 不再依赖于 Bar，并且它正在使用它自己的改变的"副本.Bar 位于另一个包中.

In order to solve this problem, developer of Foo can choose to use shade plugin to rename its usage of Bar, so that all classes in Bar:1.0 jar are embedded in Foo jar, and the package of the embedded Bar classes is changed from com.bar to com.foo.bar. By doing so, Qux can safely depends on Bar:2.0 because now Foo is no longer depending on Bar, and it is using its own copy of the "altered" Bar located in another package.

这篇关于maven-shade-plugin 的用途是什么，为什么要重新定位 Java 包?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！