事情是這樣的

前幾天遇到一個線上問題，SQL 解析直接超時了，日志里一堆 JSQLParserException: Time out occurred。排查下來發(fā)現(xiàn)是 JSqlParser 4.6 版本的一個已知 bug，解析復雜 SQL 的時候會陷入回溯地獄，CPU 直接打滿。

解決方案很簡單，升級到 4.9 就好了。但問題來了——我們項目里有好幾個庫都依賴 JSqlParser：

• mybatis-plus-core 依賴 4.6
• pagehelper 依賴 4.6
• 我們自己的 flcloud-jdbc-cipher 要用 4.9

這就尷尬了，同一個 jar 包，三個地方要三個版本，Maven 怎么處理？

Maven 的依賴仲裁機制

先說結(jié)論：Maven 不會真的引入多個版本，最終只會保留一個。

那它怎么決定保留哪個？規(guī)則其實挺簡單的：

舉個例子，假設依賴樹是這樣的：

三個 jsqlparser，深度分別是 4 層、3 層、2 層。按"路徑最短優(yōu)先"，4.9 勝出。

但實際情況往往沒這么簡單，深度可能差不多，這時候就看誰在 pom 里寫在前面了。

我當時的第一反應：到處寫 exclusion

說實話，我一開始的想法就是簡單粗暴，把不想要的版本排除掉：

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
    <exclusions>
        <exclusion>
            <groupId>com.github.jsqlparser</groupId>
            <artifactId>jsqlparser</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>com.github.pagehelper</groupId>
    <artifactId>pagehelper-spring-boot-starter</artifactId>
    <version>2.1.0</version>
    <exclusions>
        <exclusion>
            <groupId>com.github.jsqlparser</groupId>
            <artifactId>jsqlparser</artifactId>
        </exclusion>
    </exclusions>
</dependency>

能用是能用，但問題也很明顯：

• 要改好幾個地方，容易漏
• 新同事不知道這段歷史，可能哪天又加了個依賴把 4.6 帶進來
• 看著就難受，到處都是 exclusion

后來發(fā)現(xiàn)更優(yōu)雅的方式

其實 Maven 早就提供了統(tǒng)一管理依賴版本的機制：在父 pom 的 dependencyManagement 里鎖版本。

<!-- 父 pom.xml -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.github.jsqlparser</groupId>
            <artifactId>jsqlparser</artifactId>
            <version>4.9</version>
        </dependency>
    </dependencies>
</dependencyManagement>

就這么簡單。加上這段之后，不管子模塊的依賴樹里 jsqlparser 出現(xiàn)多少次、原本寫的是什么版本，最終都會被統(tǒng)一成 4.9。

改完之后跑一下 mvn dependency:tree | grep jsqlparser，確認只剩一個版本就行了。

為什么 dependencyManagement 優(yōu)先級最高

這塊我之前也沒太搞明白，后來翻了下 Maven 的文檔，大概是這么個優(yōu)先級順序：

dependencyManagement 的作用就是"預定義"版本號，它不會真的引入依賴，但一旦這個依賴在依賴樹中出現(xiàn)，就會強制使用預定義的版本。

所以它的優(yōu)先級比什么路徑深度、聲明順序都高，直接一錘定音。

幾個要注意的地方

驗證是必須的

改完版本之后，別急著提交，先驗證一下各個庫在新版本下能不能正常工作。jsqlparser 4.7 之后有些 API 變了，比如 SubSelect、SelectBody 這些類被 干掉了。如果哪個庫用到了這些老 API，啟動的時候就會報 NoSuchMethodError。

我們這次還好，mybatis-plus 和 pagehelper 用的都是比較基礎的 API，升到 4.9 之后跑了下單測，沒啥問題。

查看依賴樹的命令

# 看完整依賴樹
mvn dependency:tree

# 只看某個依賴
mvn dependency:tree | grep jsqlparser

# 更詳細的沖突分析
mvn dependency:tree -Dverbose -Dincludes=com.github.jsqlparser:jsqlparser

IDEA 也能看

如果你用 IDEA，pom 文件底部有個 "Dependency Analyzer" 標簽頁，能看到依賴樹和沖突情況，比命令行直觀多了。

總結(jié)一下

說白了就是：能用 dependencyManagement 解決的，就別到處寫 exclusion。

前者是"我說了算"，后者是"我不要這個不要那個"。心態(tài)都不一樣。

到此這篇關(guān)于一文詳解Maven中依賴沖突的正確處理方法的文章就介紹到這了,更多相關(guān)Maven依賴沖突內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論