Table of contents
1. Reasons for dependency conflicts
2. Reproduce a dependency conflict scenario
3. How to locate dependency conflicts
4. Dependency on the shortest path first principle
1. Reasons for dependency conflicts
If in the maven project, A depends on B and C, B depends on D of version 1.0, and C depends on D of version 2.0, a dependency conflict will occur at this time.
When loading and using D dependencies on A, maven will load one D dependency according to the principle of shortest dependency path , and the other will not be used.
Most of the time, dependency conflicts may not cause any exceptions to the system. However, in some specific cases, the system will report errors. For example, the version change causes the API to be different, or the class is deleted, but it happens to be used again. A changed API or a deleted class will cause the system to report an error.
2. Reproduce a dependency conflict scenario
In order to explain how to locate dependency conflicts later, here we first reproduce a dependency conflict scenario.
Three modules:
-
orderService
-
productService
-
platformService
The dependencies are as follows:
orderService depends on:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.8.1</version>
</dependency>productService depends on:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.9</version>
</dependency>Platform dependencies:
<dependency>
<groupId>org.example</groupId>
<artifactId>orderService</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.example</groupId>
<artifactId>productService</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>3. How to locate dependency conflicts
3.1.maven show dependencies
IDEA has a built-in function, maven show dependencies, which can be called up by right-clicking the pom file, or the shortcut key in the upper right corner can also be called up
maven show dependencies will show us a maven dependency tree:
Blue arrows are normal dependencies, and red arrows are dependency conflicts.
If there are too many dependencies, ctrl+F can pop up the dependency list, in which you can choose the dependencies you want to locate:
It's a pity that the scenarios of maven show dependencies are really limited. For normal projects with a small size, the dependency tree will be very large. Using this method will make people look stupid.
Here I randomly take out the dependency tree on a project that a blogger has experienced, and it looks like this:
There is no way to see this kind of dependency tree. Even if it is located, you can't find the lines of the dependency path. So there is no way? Of course there is, this is a plug-in of IDEA, our maven dependency conflict analysis tool - maven helper.
3.2.maven helper
The first is to download and install. Be sure to check it carefully. Don’t install it wrong. If there is no way to install it in IDEA, go to the official website to download it, and then install it locally offline.
Blogger, this has been installed in advance. If you install it for the first time, restart IDEA after installation to take effect.
After installing the maven helper, there will be a dependency option in the lower left corner of the pom.xml file, click this option to enter the maven helper:
The all dependencies option will display the dependency tree of the current project:
This kind of directory-level dependency tree is much friendlier than the graph when the amount of dependencies is large, and the conflicted dependencies will be marked in red, that is, the dependencies that will not be used.
The conflicts option allows you to search for dependencies based on the name of the dependency. The search results will display the effective version of the dependency. Clicking will display all versions of the dependency in the project, and the version that has been conflicted and ineffective will be marked in red:
Right-click dependencies in maven helper, you can exclude dependencies:
It will directly use exclusions to exclude dependencies:
<dependencies>
<dependency>
<groupId>org.example</groupId>
<artifactId>orderService</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.example</groupId>
<artifactId>productService</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<artifactId>commons-lang3</artifactId>
<groupId>org.apache.commons</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>4. Dependency on the shortest path first principle
Here is an extension to talk about the principle of shortest-first dependency path.
The shortest dependency path first principle is a strategy for resolving dependency conflicts. It specifies that when there are multiple conflicting dependency versions, the version with the shortest dependency path (that is, the shallowest nesting level) is selected as the solution. This principle is often used in build tools like Maven to determine which version of a library should be used in a dependency.
Here is an example of how the dependency path shortest first principle works:
Assume the following dependencies:
-
Application A depends on library B (version 1.0) and library C (version 1.0).
-
Library B depends on library C (version 2.0).
According to the principle of shortest dependency path, the way to resolve conflicts is to choose the dependency version on the shortest path. In this example, library B has the shortest dependency path, so version 1.0 of library C is chosen as the solution. Thus, library C (version 2.0) will not be selected because it has a longer path.
The purpose of this principle is to minimize potential dependency conflict issues, since generally, shorter paths mean more direct dependencies, and it may be easier to avoid conflicts.