Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to solve the Maven conflict problem". In the daily operation, I believe that many people have doubts about how to solve the Maven conflict problem. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to solve the Maven conflict problem"! Next, please follow the editor to study!

Maven Review

Maven README

Maven is a tool for building and managing Java projects. For the Java direction, Maven is almost always touched and used. Of course, there are other tools to replace Maven, such as Ant and Gradle.

Java Web projects that have previously been exposed to Grails builds use Gradle for dependency management. As for Ant, I have seen it in some old projects when I was just working, but I have hardly seen it since.

Using Maven allows us to quickly build a new project, and it is easy to integrate and manage multiple tripartite frameworks. When we need a framework, we can search for the information about the framework and configure it in your project.

For example, if you want to use Spring Boot, in addition to obtaining the dependent version in the Spring document, you can also search for it and select the corresponding version, as shown below:

You can see that the default is the dependency of Maven, and you only need to copy the entire section of dependency into the pom.xml file of the project. There are many other dependencies on the right, such as Gradle and so on.

Maven dependency transfer

Today, we will mainly talk about how to solve the problem of Jar package conflicts when Maven does dependency management. Let's understand the basic knowledge before solving it.

The figure above shows the dependency transitivity of Maven. First, Project B relies on two frameworks, Spring and Guava. Project A then relies on Project B, so Project An also relies on the Spring and Guava frameworks.

Dependency delivery Jar package selection logical dependency delivery can lead to dependencies on many other versions of Jar in the project, so how do you choose a Jar package?

There are two rules:

Different distance, short distance priority

At the same distance, the former takes priority.

As shown in the figure below, project A depends on project An and project B depends on Guava, respectively, but in terms of dependency level, project B is shallower, so Guava18.0 will be preferred.

When the distance is the same, the one defined in front will be preferred. As shown in the following figure, both Project An and Project B depend on the version of Guava15.0 and Guava18.0, respectively, but the order of Project A comes before Project B, so the Guava15.0 version is preferred.

Dependency transitivity often leads to Jar package conflicts. For example, Project An in the following figure depends on Guava15.0 and then on Project B, which relies on Guava18.0, so that Project A relies on both Guava15.0 and Guava18.0.

If you happen to use a higher version of a method and class that is not compatible with a lower version, a selection error will occur because Maven will select a shallow dependency based on the depth of the dependency tree, that is, 15.0.

Conflict case

The following is a typical Jar package conflict problem, which occurs when there are multiple versions of a Jar.

The error message can be seen that the com.google.common.collect.FluentIterable.concat method can not be found. It is currently loaded from guava-18.0.jar. How can we solve this problem?

Description: An attempt was made to call the method com.google.common.collect.FluentIterable.concat (Ljava/lang/Iterable;Ljava/lang/Iterable;) Lcom/google/common/collect/FluentIterable; but it does not exist. Its class, com.google.common.collect.FluentIterable, is available from the following locations: Its class, com.google.common.collect.FluentIterable, is available from the following locations: Its class, com.google.common.collect.FluentIterable, is available from the following locations: Its class, com.google.common.collect.FluentIterable, is available from the following locations: Its class, com.google.common.collect.FluentIterable, is available from the following locations: Its class, com.google.common.collect.FluentIterable, is available from the following locations: It was loaded from the following location: file:/Users/yinjihuan/.m2/repository/com/google/guava/guava/18.0/guava-18.0.jar Action: Correct the classpath of your application so that it contains a single Compatible version of com.google.common.collect.FluentIterable

To solve the problem of hanging silk and feeling pulse

Identify conflicting Jar and see which versions are relied on in the current project.

Eclipse

In Eclipse, you can double-click the pom file, enter the Dependency view, enter the name of the jar you want to search for, and you can see which frameworks in the current project depend on the jar you search, and what version can be known.

Idea

You can install the maven helper plug-in in Idea to view the relevant dependency information. Selecting Conflicts by default will show that there are conflicting dependencies in the current project. Of course, we can also directly view the tree dependencies to analyze the conflicts.

Maven command

Instead of using plug-ins of development tools, we can directly use the Maven command to view the dependencies of the current project. The command line goes to the project directory you want to analyze, and execute the following command to save the analysis results to a file:

Mvn dependency:tree > tree.log

The dependent information structure after execution is as follows:

After searching guava, I found that I relied on version 18.0 in smjdbctemplate, which is my own framework based on jdbctemplate encapsulation.

The observation of the solution is actually very obvious, the error message has told us that the concat method can not be found in 18.0, so 18.0 must not be used. Through the previous analysis, it is found that the one that directly depends on guava.18.0.jar is smjdbctemplate, and the solution is to eliminate guava in smjdbctemplate.

Com.github.yinjihuan smjdbctemplate 1.1 com.google.guava guava

Another is to determine which version the current project depends on according to the depth of the dependency tree, as shown below:

18.0 is the shallowest, and definitely depends on it. In fact, you can directly view Maven Dependencies in Eclipse to specify which framework and version information the current project depends on, as shown below:

When we rule out 18.0, the dependent version is 20.0, as shown below:

Depending on the depth of the dependency tree, 20.0 and 19.0 are at the same level, but 20.0 is prior to 19.0, so version 20.0 is preferred.

Looking at the pom file in the project, it is found that the declaration order of swagger comes before apollo.

If we adjust the order, we will rely on version 19.0.

At this point, the study on "how to solve the problem of Maven conflict" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.