Maven如何解决传递依赖关系的版本冲突？最近胜利的策略 [英] How does Maven resolve version conflicts of transitive dependencies ? nearest-wins strategy

问题描述

我刚刚终于习惯了在我的项目中没有使用未声明或未使用声明的依赖项。虽然很难跟踪在依赖关系中列出的未使用的声明的运行时/测试依赖关系：分析...只需在pom.xml中写入注释，或以其他方式管理它们，以便知道它们是测试或运行时所需的。 / p>

但解决版本冲突的方式对我来说还不清楚。关于传递依赖。

最近的胜利策略如何正确运作？什么时候使用另一个版本的版本？

• 如果您使用版本号声明使用未声明的依赖关系 - 它总是赢得




• 如果没有明确指定依赖关系版本，Maven无法解决任何版本的
  冲突，可能会出现这种依赖关系（很奇怪，但写了 here ）




• 如果您不声明Undeclared使用依赖关系，则从最接近的级别（最近的胜利策略）中选择一个传递依赖关系，如果冲突在同一级别，那么它会以某种方式决定版本A之间的版本B ...也许处理依赖关系的第一个获胜

解决方案

依赖解决方法与您所描述的完全相同。

我还认为，如果您使用< scope> 从maven官方网站引用的< dependency>

的子标签

1. 编译：
   这是默认范围，如果没有指定，则使用。编译依赖项可在项目的所有类路径中使用。此外，这些依赖关系被传播到依赖项目。


2. 提供：这很像编译，但表示您期望JDK或容器在运行时提供依赖关系。例如，当为Java Enterprise Edition构建Web应用程序时，您将设置对Servlet API和相关Java EE API的依赖关系，因为Web容器提供了这些类。此范围仅适用于编译和测试类路径，不可传递。


3. 运行时此范围表示编译不需要依赖关系，而是用于执行。它在运行时和测试类路径中，但不是编译类路径。


4. test：此范围表示正常使用应用程序不需要依赖关系，并且仅适用于测试编译和执行阶段。


5. 系统：此范围与提供的类似，只是您必须提供明确包含它的JAR。该工件始终可用，并且不会在存储库中查找。


6. import :(仅在Maven 2.0.9或更高版本中可用）
   此范围仅用于依赖关系的类型pom在该部分。它表示指定的POM应替换为该POM部分的依赖关系。由于它们被替换，与导入范围的依赖关系实际上并不参与限制依赖关系的传递性。

I just finally got used to not having any Used undeclared or Unused declared dependencies in my projects. Although it is very hard to track Unused declared runtime/test dependencies that are listed in dependency:analyze... One just must write comments to them in pom.xml or otherwise manage them to know that they are needed for testing or runtime.

But the way of resolving version conflict is still unclear to me. Regarding transitive dependencies.

How does the nearest-wins strategy work exactly? When is one version used over another version ?

• If you declare the Used undeclared dependency with a version number - it always wins

• If one doesn't specify dependency version explicitly, Maven cannot resolve any version conflicts that may arise regarding this dependency (weird, but written here)

• If you don't declare Undeclared used dependency, it chooses a transitive dependency from the closest level (nearest-wins strategy) and if the conflict is on the same level then it somehow decides between version A over version B ... Maybe the first one it comes to when processing the depenencies wins

解决方案

I think the dependency resolution works the exact same way you described.

I also think your life would be much easier if you use the <scope> child tag to your <dependency>

as quoted from the maven official website:

1. compile: This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
2. provided: This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
3. runtime This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
4. test: This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
5. system: This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
6. import: (only available in Maven 2.0.9 or later) This scope is only used on a dependency of type pom in the section. It indicates that the specified POM should be replaced with the dependencies in that POM's section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

这篇关于Maven如何解决传递依赖关系的版本冲突？最近胜利的策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！