一加Ace2 Pro官宣：普及16G內存 引領24G
一加官方今天繼續為本月發布的新機一加Ace2 Pro帶來預熱，公布了內存方面的信息。“淘汰 8GB ，12GB 起步，16GB 普及，24GB 引領，還有呢？#一加Ace2Pro#，2023 年 8 月，敬請期待。”同時
依賴沖突是指：在 Maven 項目中，當多個依賴包，引入了同一份類庫的不同版本時，可能會導致編譯錯誤或運行時異常。
我們在 Maven 項目的 Pom 中 一般會引用許許多多的 Dependency。例如，項目A有這樣的依賴關系：
A -> C -> X(1.0)B -> D -> X(2.0)X是A的 傳遞性依賴 ，但是兩條依賴路徑上有兩個版本的X,那么哪個X會被 Maven 解析使用呢? 兩個版本都被解析顯然是不對的，因為那會造成依賴重復，因此必須選擇一個。
在絕對大多數情況下，依賴沖突問題并不需要我們考慮，Maven 工具會自動根絕依賴原則選擇，這里我們先假設最終引用的 X(1.0) 版本，
1、你想如果B引用 X(2.0) 的新創建的類，但因為最終被解析的是 X(1.0)，所以就會出現很典型的 NoClassDefFoundError 或 ClassNotFoundException 依賴沖突報錯。
2、如果B引用 X(2.0) 的新創建的方法，但因為最終被解析的是 X(1.0)，所以就會拋出 NoSuchMethodError 系統異常。
但換種角度，如果最終解析的是 X(2.0)，就沒問題了嗎？
1、如果 X(2.0) 刪掉了 X(1.0) 的一些類，但A已經引用了，同樣也會報 NoClassDefFoundError 或者 ClassNotFoundException 錯誤。
2、如果 X(2.0) 刪掉了 X(1.0) 的一些方法，但A已經引用了，同樣也會報 NoSuchMethodError 錯誤。
所以說具體問題還需具體分析，到底采用哪個版本還需要看實際項目。也可能我們需要升級對應的A或者B的版本才能解決問題。
在同一個 Pom 內，相同 Jar 不同版本，根據依賴的路徑長短來決定引入哪個依賴。
舉例
依賴鏈路一：A -> B -> C -> X(1.0)依賴鏈路二：F -> D -> X(2.0)該例中 X(1.0) 的路徑長度為3,而 X(2.0) 的路徑長度為2,因此 X(2.0) 會被解析使用。依賴調解第一原則不能解決所有問題，比如這樣的依賴關系：
A -> B -> Y(1.0)c -> D -> Y(2.0)Y(1.0) 和 Y(2.0) 的依賴路徑長度是一樣的，都為2。Maven 定義了依賴調解的第二原則：
在依賴路徑長度相等的前提下，在同一個 Pom 中，間接依賴聲明的順序決定了誰會被解析使用，順序最前的那個依賴優勝。該例中，如果A的依賴聲明在C之前，那么 Y (1.0) 就會被解析使用.
比如 我在 demo01 中引入了 demo02 和 demo03，demo02 和 demo03 都引入了 Lombok 的依賴
圖片
demo02 和 demo03 換個順序
圖片
圖片
圖片
我們先來解釋下什么是傳遞性依賴
比如當我們項目中，引用了A的依賴,A的依賴通常又會引入B的 Jar 包，B可能還會引入C的 Jar 包。
這樣，當你在 pom.xml 文件中添加了A的依賴，Maven 會自動的幫你把所有相關的依賴都添加進來。
就這樣一層層的，Maven 會自動的幫你把所有相關的依賴都添加進來。傳遞性依賴會給項目引入很多依賴，簡化項目依賴管理，但是也會帶來問題。
最明顯的就是容易發生依賴沖突。
這種情況下，想要解決依賴沖突，可以靠升級/降級某些依賴項的版本，從而讓不同依賴引入的同一類庫，保持一致的版本號。另外，還可以通過隱藏依賴、或者排除特定的依賴項來解決問題。
Exclusions是主動斷開依賴的資源，被排除的資源無需指定版本—指不需要
也就是說可以包含一個或者多 Exclusion 子元素，因此可以排除一個或者多個傳遞性依賴。需要注意的是，聲明 Exclusion 的時候只需要 Groupld 和 Artifactld ,而不需要要 Version 元素。
用法示例：
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>5.1.8.RELEASE</version> <exclusions> <!-- 排除web包依賴的beans包 --> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> </exclusion> </exclusions></dependency>該標簽即是“隱藏依賴”的開關,指對外隱藏當前所依賴的資源---指不透明：
用法示例：<dependency> <groupId>org.springframework</groupId> <artifactId>spring-aop</artifactId> <version>5.1.8.RELEASE</version> <optional>true</optional></dependency>
圖片
圖片
圖片
聚合工程，即是指：一個項目允許創建多個子模塊，多個子模塊組成一個整體，可以統一進行項目的構建。要弄明白聚合工程，得先清楚“父子工程”的概念：
而Maven聚合工程，就是基于父子工程結構，來將一個完整項目，劃分出不同的層次，這種方式可以很好的管理多模塊之間的依賴關系，以及構建順序，大大提高了開發效率、維護性。
為了防止不同子工程引入不同版本的依賴，在父工程中，統一對依賴的版本進行控制，規定所有子工程都使用同一版本的依賴，可以使用<dependencyManagement>標簽來管理。
子工程在使用<dependencyManagement>中已有的依賴項時，不需要寫<version>版本號，版本號在父工程中統一管理，這樣做的好處在于：以后為項目的技術棧升級版本時，不需要單獨修改每個子工程的POM，只需要修改父POM文件即可，減少了版本沖突的可能性。
如果你的項目中依賴許許多多的 Jar ，肉眼排查就沒那么方便了，這里推薦一個 Maven 管理插件
圖片
在 Pom 文件中看到 Dependency Analyzer標志，說明 Maven Helper 插件就安裝成功了。
圖片
點擊 Dependency Analyzer 之后就會進入到下面的頁面
圖片
從圖中可以看出有哪些jar存在沖突，存在沖突的情況下最終采用了哪個依賴的版本。標紅的就是沖突版本，白色的是當前的解析版本。
如果我們想保留標紅的版本，那我們可以標白區域右擊選擇排除(Exclude)即可。
一般我們在解決依賴沖突的時候，都會選擇保留jar高的版本，因為大部分jar在升級的時候都會做到向下兼容，所以只要保留高的版本就不會有什么問題。
但是有些包，版本變化大沒法去做向下兼容，高版本刪了低版本的某些類或者某些方法，那么這個時候就不能一股腦的去選擇高版本，但也不能選擇低版本。
就比如下面這個案例
依賴鏈路一：A -> B -> C -> X(1.0)依賴鏈路二：F -> D -> X(2.0)X(2.0) 沒有對 X(1.0) 做向下兼容也就是說可能存在排除哪個都不行，那怎么辦我們只能考慮升級A的版本或者降低F的版本。比如A升級到A(2.0),使它依賴的X版本變成X(2.0)這樣的話就解決依賴沖突。
但話有說回來 A升級到A(2.0) 可能會影響許許多多的地方，比如自己項目中代碼是否需要改變，或者因為 A升級到A(2.0) 導致 B和C的版本有所改變，這些影響點都需要我們去考慮的。所以說為什么說一個大型項目穩定后，Pom文件的升級是件繁瑣的事情，那是因為考慮的東西是在太多了，稍有不慎就會因為依賴沖突而導致系統報錯。
本文鏈接：http://m.www897cc.com/showinfo-26-75318-0.html我們一起聊聊 Maven 依賴沖突問題
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 想徒手寫個文件系統？來一起呀
下一篇： 前端視角對Rust的淺析
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號