Maven解決jar包衝突示例

 項目背景：在使用grpc遠程連接框架時，導入jar包至已有的項目，在客戶端與服務器連接時，一直報錯：NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;J)V

產生原因：由於項目中已經有guava包，且版本是18.0.0.而grpc同樣依賴這個包，但是grpc依賴的guava版本需要20.0.0版本以上，所以報錯。

排查問題過程： 1，百度錯誤，查詢到一堆的雜七雜八的回答。

                          2，檢查grpc引入的jar包是否有問題，替換成官方文檔給出的示例。另寫了一個獨立的demo，嘗試連接客戶端和服務端，連接成功。說明jar包沒有引入錯誤。檢查demo和已有工程的區別。

                          3，結合百度答案，縮減答案範圍，懷疑是jar包衝突。利用idea工具，查看jar包的依賴關係。發現原先項目中guava已經存在且版本爲18.0.0. 爲是因確認版本造成報錯，將demo中的guava版本換成18.0.0（在pom文件中顯示添加guava的jar包），發現連接失敗，且錯誤信息一致。確認是由jar包版本過低導致連接失敗。

                          4，思考如何替換guava版本，惡補maven知識。

                           利用maven最短路徑優先原則以及最先聲明原則：直接在使用到grpc的工程下，在pom文件的最開始位置引入20.0.0版本的jar包

                          最大路徑優先原則：

                               D1和D2是相同jar包的不同版本

                               Maven 面對 D1 和 D2 時，會默認選擇最短路徑的那個 jar 包，即 D2。E->F->D2 比 A->B->C->D1 路徑短 1。

                          最先聲明優先：

                               如果路徑一樣的話，如： A->B->D1, E->F->D2 ，兩個依賴路徑長度都是 2，那麼就選擇最先聲明。

                         體現在pom文件中是：從上到下，上爲先

                           jar包衝突解決參考：https://blog.csdn.net/noaman_wgs/article/details/81137893