雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
前言
在如今的網際網路項目開發當中，特别是Java領域，可以說Maven随處可見。Maven的倉庫管理、依賴管理、繼承和聚合等特性為項目的建構提供了一整套完善的解決方案，可以說如果你搞不懂Maven，那麼一個多子產品的項目足以讓你頭疼，依賴沖突就會讓你不知所措，甚至搞不清楚項目是如何運作起來的.....OK，部落客就曾經被Maven“傷害”過，那麼該專題的目的就是：徹底搞定Maven！
Thinking in Maven
回想一下，當你新到一家公司，安裝完JDK後就會安裝配置Maven（MAVEN_HOME、path），很大可能性你需要修改settings.xml檔案，比如你會修改本地倉庫位址路徑，比如你很可能會copy一段配置到你的settings.xml中（很可能就是私服的一些配置）。接下來，你會到IDEA或者Eclipse中進行Maven插件配置，然後你就可以在工程中的pom.xml裡面開始添加标簽來管理jar包，在Maven規範的目錄結構下進行編寫代碼，最後你會通過插件的方式來進行測試、打包（jar or war）、部署、運作。
上面描述了我們對Maven的一些使用方式，下面我們進行一些思考：
Q1：本地倉庫？Maven到底有哪些倉庫？它們什麼關系？
你要jar包，不可能每次都要聯網去下載下傳吧，多費勁，是以本地倉庫就是相當于加了一層jar包緩存，先到這裡來查。如果這裡查不到，那麼就去私服上找，如果私服也找不到，那麼去中央倉庫去找，找到jar後，會把jar的資訊同步到私服和本地倉庫中。
私服，就是公司内部區域網路的一台伺服器而已，你想一下，當你的工程Project-A依賴别人的Project-B的接口，怎麼做呢？沒有Maven的時候，當然是copy Project-B jar到你的本地lib中引入，那麼Maven的方式，很顯然需要其他人把Project-B deploy到私服倉庫中供你使用。是以私服中存儲了本公司的内部專用的jar！不僅如此，私服還充當了中央倉庫的鏡像，說白了就是一個代理！
中央倉庫：該倉庫存儲了網際網路上的jar，由Maven團隊來維護，位址是：
http://repo1.maven.org/maven2/。
Q2：關于的使用
其實這個标簽揭示了jar的查找坐标：groupId、artifactId、version。
一般而言，我們可以到私服上輸入artifactId進行搜尋，或者到
http://search.maven.org/、
http://mvnrepository.com/上進行查找确定坐标。
version分為開發版本（Snapshot）和釋出版本（Release），那麼為什麼要分呢？
在實際開發中，我們經常遇到這樣的場景，比如A服務依賴于B服務，A和B同時開發，B在開發中發現了BUG，修改後，将版本由1.0更新為2.0，那麼A必須也跟着在POM.XML中進行版本更新。過了幾天後，B又發現了問題，進行修改後更新版本釋出，然後通知A進行更新...可以說這是開發過程中的版本不穩定導緻了這樣的問題。
Maven，已經替我們想好了解決方案，就是使用Snapshot版本，在開發過程中B釋出的版本标志為Snapshot版本，A進行依賴的時候選擇Snapshot版本，那麼每次B釋出的話，會在私服倉庫中，形成帶有時間戳的Snapshot版本，而A建構的時候會自動下載下傳B最新時間戳的Snapshot版本！
Q3：既然Maven進行了依賴管理，為什麼還會出現依賴沖突？處理依賴沖突的手段是？
首先來說，對于Maven而言，同一個groupId同一個artifactId下，隻能使用一個version！
根據上圖的依賴順序，将使用1.2版本的jar。
現在，我們可以思考下了，比如工程中需要引入A、B，而A依賴1.0版本的C，B依賴2.0版本的C，那麼問題來了，C使用的版本将由引入A、B的順序而定？這顯然不靠譜！如果A的依賴寫在B的依賴後面，将意味着最後引入的是1.0版本的C，很可能在運作階段出現類（ClassNotFoundException）、方法（NoSuchMethodError）找不到的錯誤（因為B使用的是高版本的C）！
這裡其實涉及到了2個概念：依賴傳遞（transitive）、Maven的最近依賴政策。
依賴傳遞：如果A依賴B，B依賴C，那麼引入A，意味着B和C都會被引入。
Maven的最近依賴政策：如果一個項目依賴相同的groupId、artifactId的多個版本，那麼在依賴樹（mvn dependency:tree）中離項目最近的那個版本将會被使用。（從這裡可以看出Maven是不是有點小問題呢？能不能選擇高版本的進行依賴麼？據了解，Gradle就是version+政策）
現在，我們可以想想如何處理依賴沖突呢？
想法1：要使用哪個版本，我們是清楚的，那麼能不能不管如何依賴傳遞，都可以進行版本鎖定呢？
使用 [這種主要用于子子產品的版本一緻性中]
想法2：在依賴傳遞中，能不能去掉我們不想依賴的？
使用 [在實際中我們可以在IDEA中直接利用插件幫助我們生成]
想法3：既然是最近依賴政策，那麼我們就直接使用顯式依賴指定版本，那不就是最靠近項目的麼？
使用
Q4：引入依賴的最佳實踐，提前發現問題！
在工程中，我們避免不了需要加一些依賴，也許加了依賴後運作時才發現存在依賴沖突在去解決，似乎有點晚！那麼能不能提前發現問題呢？
如果我們新加入一個依賴的話，那麼先通過mvn dependency:tree指令形成依賴樹，看看我們新加入的依賴，是否存在傳遞依賴，傳遞依賴中是否和依賴樹中的版本存在沖突，如果存在多個版本沖突，利用上文的方式進行解決！
Q5：Maven規範化目錄結構
這裡需要注意2點：
第一：src/main下内容最終會打包到Jar/War中，而src/test下是測試内容，并不會打包進去。
第二：src/main/resources中的資源檔案會COPY至目标目錄，這是Maven的預設生命周期中的一個規定動作。（想一想，hibernate/mybatis的映射XML需要放入resources下，而不能在放在其他地方了）
Q6：Maven的生命周期
我們隻需要注意一點：執行後面的指令時，前面的指令自動得到執行。
實際上，我們最常用的就是這麼幾個：
clean：有問題，多清理！
package：打成Jar or War包，會自動進行clean+compile
install：将本地工程Jar上傳到本地倉庫
deploy：上傳到私服
Q7：關于scope依賴範圍
既然，Maven的生命周期存在編譯、測試、運作這些過程，那麼顯然有些依賴隻用于測試，比如junit；有些依賴編譯用不到，隻有運作的時候才能用到，比如mysql的驅動包在編譯期就用不到（編譯期用的是JDBC接口），而是在運作時用到的；還有些依賴，編譯期要用到，而運作期不需要提供，因為有些容器已經提供了，比如servlet-api在tomcat中已經提供了，我們隻需要的是編譯期提供而已。
總結來說：
compile：預設的scope，運作期有效，需要打入包中。
provided：編譯期有效，運作期不需要提供，不會打入包中。
runtime：編譯不需要，在運作期有效，需要導入包中。（接口與實作分離）
test：測試需要，不會打入包中。
system：非本地倉庫引入、存在系統的某個路徑下的jar。（一般不使用）
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-04-01
本文作者：張豐哲
本文來自：“
網際網路架構師 微信公衆号”，了解相關資訊可以關注“
網際網路架構師”