什么是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 docs ，但是我无法理解这句话：

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

这个插件提供了将工件打包成超级的功能 - 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中。通过拥有这样的超级jar，它很容易执行，因为你只需要一个大的JAR而不是大量的小JAR来运行你的应用程序。在某些情况下，它也便于分发。

An uber-jar is something that take all dependencies, and extract the content of the dependencies and put them with the classes/resources of the project itself, in one big JAR. By having such 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 ease distribution in some case.

只是一个附注。避免使用uber-jar作为Maven依赖，因为它破坏了Maven的依赖性解析功能。通常我们只为实际部署或手动分发的最终工件创建uber-jar，但不是为了放到Maven存储库。

Just a side-note. Avoid using uber-jar as Maven dependency, as it is ruining the dependency resolution feature of Maven. Normally we create 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 is some brief updates and hopefully will help people having similar question.

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

Creating uber-jar for ease of deployment is one use case of 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 需要使用中的新功能条：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 is own copy of "altered" Bar located in another package.

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