spring 为什么 Maven 依赖项的顺序很重要？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/31740785/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why order of Maven dependencies matter?
提问by Elderry
I thought that the order of Maven dependencies doesn't matter before and regard this as a pro of it. And this is my old pom.xml's dependencies:
我以前认为 Maven 依赖项的顺序无关紧要，并认为这是它的优点。这是我的 oldpom.xml的依赖项：
<dependencies>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.19</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>4.1.7.RELEASE</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring3</artifactId>
<version>2.19</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-moxy</artifactId>
<version>2.19</version>
</dependency>
</dependencies>
It works well, and today I wanna move spring dependency to the bottom so that those jersey related can be together. However then I can no longer make it working, my Jetty complains:
效果很好，今天我想把 spring 依赖移到底部，这样那些球衣相关的就可以在一起了。但是后来我不能再让它工作了，我的码头抱怨：
[ERROR] Failed to execute goal org.eclipse.jetty:jetty-maven-plugin:9.3.0.M1:run (default-cli) on project mtest: Execution default-cli of goal org.eclipse.jetty:jetty-maven-plugin:9.3.0.M1:run failed: A required class was missing while executing org.eclipse.jetty:jetty-maven-plugin:9.3.0.M1:run: org/apache/commons/logging/LogFactory
That is really confusing, so do I have to concern about dependencies order? How do I know the correct order?
这真的很令人困惑，所以我必须关心依赖顺序吗？我怎么知道正确的顺序？
回答by kryger
The order of dependencies doesmatter because of how Maven resolves transitive dependencies, starting with version 2.0.9. Excerpt from the documentation:
从 2.0.9 版开始，依赖项的顺序确实很重要，因为 Maven 如何解决传递依赖项。文档摘录：
(...) this determines what version of a dependency will be used when multiple versions of an artifact are encountered. (...) You can always guarantee a version by declaring it explicitly in your project's POM. (...) since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.
(...) 这决定了当遇到多个版本的工件时将使用哪个版本的依赖项。(...) 您始终可以通过在项目的 POM 中明确声明来保证版本。(...) 从 Maven 2.0.9 开始，声明中的顺序是重要的：第一个声明获胜。
回答by Kyle Krull
To expand upon the other answer (which states that the declaration order affects Maven's dependency mediation for transitive dependencies), there are a few tools you can use:
为了扩展另一个答案（它指出声明顺序会影响 Maven 对传递依赖的依赖中介），您可以使用一些工具：
mvn dependency:tree [-Dscope=[runtime|test]]will show you what dependencies will be available for the selected scope. See here for detailsmvn dependency:build-classpathgives you order in which dependencies are available on your classpath (if two or more classpath entries have the same class, the earlier one wins). See here for details
mvn dependency:tree [-Dscope=[runtime|test]]将向您显示可用于所选范围的依赖项。 详情请看这里mvn dependency:build-classpath为您提供类路径上可用依赖项的顺序（如果两个或多个类路径条目具有相同的类，则较早者获胜）。 详情请看这里
I don't know much about your situation, but it's often the case that you wind up with the wrong version of 1 or more jars at compile/runtime. Declaring your own version of the library in question or locking down the versionwith <dependencyManagement>are options here.
我不太了解您的情况，但通常情况下您会在编译/运行时得到 1 个或多个 jar 的错误版本。 声明自己的库版本有问题或版本锁定下来用<dependencyManagement>是选择这里。
Now to answer your other question - how do you know what the right order is when declaring dependencies?
现在来回答您的另一个问题 -在声明依赖项时，您如何知道正确的顺序是什么？
My suggestion - the right declaration order is the one that gets you the versions of the dependencies you want, in the order you want them in. Use the tools above to check your dependencies, and tweak the declared order if necessary.
我的建议 -正确的声明顺序是按照您希望它们在. 使用上面的工具检查您的依赖项，并在必要时调整声明的顺序。
Note that most jars contain disjointedly-named classes, so the exact order in which jars appear on your classpath is usually not that important. The only exception I've noticed is some jars in SLF4Jwhich intentionally shadow classes from the other logger libraries it's intended to replace.
请注意，大多数 jar 包含不相交命名的类，因此 jar 出现在类路径中的确切顺序通常并不那么重要。我注意到的唯一例外是SLF4J中的一些 jars，它们有意从它打算替换的其他记录器库中隐藏类。
