怎么解決Maven沖突問題

這篇文章主要介紹“怎么解決Maven沖突問題”，在日常操作中，相信很多人在怎么解決Maven沖突問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么解決Maven沖突問題”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Maven 回顧

Maven 自述

Maven 是用于構建和管理 Java 項目的工具。對于 Java 方向的來說，Maven 幾乎都要接觸和使用。當然也有其他的工具來代替  Maven，比如 Ant 和 Gradle。

之前有接觸過 Grails 構建的 Java Web 項目，就是用 Gradle 來做依賴管理的。至于 Ant  也在剛工作的時候在一些老項目中有見到過，后面幾乎沒見過了。

使用 Maven  可以讓我們快速構建一個新的項目，并且很方便的可以集成和管理多個三方的框架。當我們需要某個框架時可以去搜索一下這個框架的信息，然后配置到你的項目中即可。

比如我們想要使用 Spring Boot，除了在 Spring 的文檔中獲取依賴的版本，也可以自己去搜索，選擇對應的版本，如下圖：

可以看到默認就是 Maven 的依賴方式，只需要將 dependency 整段內容復制到項目的 pom.xml  文件中即可。右側還有很多其他的依賴方式，比如 Gradle 等。

Maven 依賴傳遞

今天主要講下如何去解決 Maven 做依賴管理的時候 Jar 包沖突的問題，在解決之前先來了解下基本的知識。

上圖展示了 Maven 的依賴傳遞性，首先是項目 B 中依賴了 Spring 和 Guava 兩個框架。然后項目 A 又依賴了項目 B，所以項目 A  也會依賴 Spring 和 Guava 兩個框架。

依賴傳遞 Jar 包選擇邏輯依賴性傳遞會導致項目中依賴很多其他版本的 Jar，這種情況下怎么進行 Jar 包的選擇呢?

有兩個規則：

• 不同距離，距離近優先

• 相同距離，前者優先

如下圖所示，項目依賴了項目 A 和項目 B，A 和 B 分別依賴了 Guava，但是從依賴層次來看，項目 B 的層次更淺，故 Guava18.0  會被優先選擇。

當距離相同的時候，就會優先選擇定義在前面的，如下圖所示，項目 A 和項目 B 都分別依賴了 Guava15.0 和 Guava18.0 的版本，但是項目  A 的順序在項目 B 的前面，所以會優先選擇 Guava15.0 版本。

通過依賴傳遞性經常會導致 Jar 包沖突的問題，比如下圖的項目 A 本身依賴了 Guava15.0，然后又依賴了項目 B，項目 B 中依賴了  Guava18.0，這樣項目 A 就會同時依賴 Guava15.0 和 Guava18.0。

如果剛好用到了高版本不兼容低版本的方法和類時，就會出現選擇錯誤，因為 Maven 會根據依賴樹的深淺來選型淺的依賴，也就是 15.0。

沖突案例

下面就是一個典型的 Jar 包沖突問題，當一個 Jar 有多個版本的時候，就會出現沖突。

錯誤信息可以看到 com.google.common.collect.FluentIterable.concat 這個方法找不到，目前是從  guava-18.0.jar 中加載的，這種問題我們該怎么解決呢?

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:     jar:file:/Users/yinjihuan/.m2/repository/com/google/guava/guava/18.0/guava-18.0.jar!/com/google/common/collect/FluentIterable.class 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

解決思路之懸絲診脈

找出沖突的 Jar，看看當前項目中依賴了哪幾個版本。

Eclipse

在 Eclipse 中可以雙擊 pom 文件，進入 Dependency 視圖，輸入你要搜索的 jar  名稱進行搜索，就可以看出當前項目中哪些框架依賴了你搜索的 jar，什么版本都能知道。

Idea

Idea 中可以安裝 maven helper 插件來查看相關依賴信息，默認選中 Conflicts  會展示當前項目存在沖突的依賴，當然我們也可以直接查看樹形的依賴關系去分析沖突。

Maven 命令

不用不借助于開發工具的插件，我們可以直接用 Maven  命令來查看當前項目的依賴關系，命令行進入到你要分析的項目目錄下，執行下面的命令將分析結果保存到文件中：

mvn dependency:tree > tree.log

執行完之后依賴的信息結構如下：

搜索了下 guava，發現在 smjdbctemplate 中依賴了 18.0 版本，這個框架是我自己基于 jdbctemplate  封裝的一個框架。

解決思路之察言觀色其實很明顯，錯誤信息已經告訴我們 18.0 中找不到 concat 方法，所以 18.0 肯定是不能用的，通過前面的分析，找到了直接依賴  guava.18.0.jar 的是 smjdbctemplate，解決辦法就是將 smjdbctemplate 中的 guava 排除掉。

<dependency>   <groupId>com.github.yinjihuan</groupId>   <artifactId>smjdbctemplate</artifactId>   <version>1.1</version>   <exclusions>     <exclusion>       <groupId>com.google.guava</groupId>       <artifactId>guava</artifactId>     </exclusion>   </exclusions> </dependency>

還有就是根據依賴樹的深淺度來判斷當前項目依賴的是哪個版本，如下圖:

18.0 是最淺的，肯定是依賴它，其實在 Eclipse 里面直接查看 Maven Dependencies  就可以指定當前項目依賴哪些框架和版本信息，如下圖：

當我們排除掉 18.0 后再來看依賴的版本是 20.0，如下圖：

根據依賴樹的深淺度，20.0 和 19.0 都是一樣的層級，但是 20.0 在 19.0 前面，所以優先選擇 20.0 版本。

再來看項目中的 pom 文件，發現 swagger 的聲明順序在 apollo 的前面。

如果我們把順序調整一下，那么就會依賴 19.0 的版本。

到此，關于“怎么解決Maven沖突問題”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！