Maven這3個問題你思考過沒有？

Maven的倉庫管理、依賴管理、繼承和聚合等特性為項目的建構提供了一整套完善的解決方案，如果你搞不懂Maven，那麼一個多子產品的項目足以讓你頭疼，依賴沖突就會讓你不知所措，甚至搞不清楚項目是如何運作起來的...

回想一下，當你新到一家公司，安裝完JDK後就會安裝配置Maven，很大可能性你需要修改settings.xml檔案，比如你會修改本地倉庫位址路徑，比如你很可能會copy一段配置到你的settings.xml中（很可能就是私服的一些配置）。

接下來，你會到IDEA或者Eclipse中進行Maven插件配置，然後你就可以在工程中的pom.xml裡面開始添加标簽來管理jar包，在Maven規範的目錄結構下進行編寫代碼，最後你會通過插件的方式來進行測試、打包（jar or war）、部署、運作。

上面描述了對Maven的一些使用方式，下面我們進行一些思考：

1、本地倉庫？Maven到底有哪些倉庫？它們什麼關系？

Maven倉庫：

你要jar包，不可能每次都要聯網去下載下傳吧，多費勁，是以本地倉庫就是相當于加了一層jar包緩存，先到這裡來查。如果這裡查不到，那麼就去私服上找，如果私服也找不到，那麼去中央倉庫去找，找到jar後，會把jar的資訊同步到私服和本地倉庫中。

私服，就是公司内部區域網路的一台伺服器而已，你想一下，當你的工程Project-A依賴别人的Project-B的接口，怎麼做呢？沒有Maven的時候，當然是copy Project-B jar到你的本地lib中引入

那麼Maven的方式，很顯然需要其他人把Project-B deploy到私服倉庫中供你使用。是以私服中存儲了本公司的内部專用的jar！不僅如此，私服還充當了中央倉庫的鏡像，說白了就是一個代理！

2、關于的使用

依賴管理：

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版本！

3、既然Maven進行了依賴管理，為什麼還會出現依賴沖突？處理依賴沖突的手段是？

首先來說，對于Maven而言，同一個groupId同一個artifactId下，隻能使用一個version！

現在，我們可以思考下了，比如工程中需要引入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+政策）

如果你想開發小程式或者了解小程式更多的内容，可以通過第三方專業開發平台，來幫助你實作開發需求：

廈門在乎科技

-專注小程式開發、

廈門app開發公司

、網站開發、H5小遊戲開發