常用指令
maven 命令的格式為 mvn [plugin-name]:[goal-name]，可以接受的參數(shù)如下。
-D 指定參數(shù)，如 -Dmaven.test.skip=true 跳過單元測試；
-P 指定 Profile 配置，可以用于區(qū)分環(huán)境；
-e 顯示maven運行出錯的信息；
-o 離線執(zhí)行命令,即不去遠程倉庫更新包；
-X 顯示maven允許的debug信息；
-U 強制去遠程更新snapshot的插件或依賴，默認每天只更新一次。
# maven 打包：
mvn package
# 編譯源代碼：
mvn compile
# 編譯測試代碼：
mvn test-compile
# 運行測試：
mvn test
# 打版本
mvn versions:set -DnewVersion=1.3.3-SNAPSHOT
# 顯示maven依賴樹：
mvn dependency:tree
# 創(chuàng)建maven項目
mvn archetype:create
# 指定 group：
-DgroupId=packageName
# 指定 artifact：
-DartifactId=projectName
# 創(chuàng)建web項目：
-DarchetypeArtifactId=maven-archetype-webapp
# 創(chuàng)建maven項目：
mvn archetype:generate
#驗證項目是否正確：
mvn validate
# 只打jar包：
mvn jar:jar
# 生成源碼jar包：
mvn source:jar
# 產(chǎn)生應用需要的任何額外的源代碼：
mvn generate-sources
# 運行檢查：
mvn verify
# 清理maven項目：
mvn clean
# 生成eclipse項目：
mvn eclipse:eclipse
# 清理eclipse配置：
mvn eclipse:clean
# 生成idea項目：
mvn idea:idea
# 安裝項目到本地倉庫：
mvn install
# 發(fā)布項目到遠程倉庫：
mvn:deploy
# 在集成測試可以運行的環(huán)境中處理和發(fā)布包：
mvn integration-test
# 顯示maven依賴列表：
mvn dependency:list
# 下載依賴包的源碼：
mvn dependency:sources
# 安裝本地jar到本地倉庫：
mvn install:install-file -DgroupId=packageName -DartifactId=projectName -Dversion=version -Dpackaging=jar -Dfile=path
本地倉庫與遠程倉庫
關于<dependency>的使用
其實這個標簽揭示了jar的查找坐標：groupId、artifactId、version。
version分為開發(fā)版本（Snapshot）和發(fā)布版本（Release），那么為什么要分呢？
在實際開發(fā)中，我們經(jīng)常遇到這樣的場景，比如A服務依賴于B服務，A和B同時開發(fā)，B在開發(fā)中發(fā)現(xiàn)了BUG，修改后，將版本由1.0升級為2.0，那么A必須也跟著在POM.XML中進行版本升級。過了幾天后，B又發(fā)現(xiàn)了問題，進行修改后升級版本發(fā)布，然后通知A進行升級...可以說這是開發(fā)過程中的版本不穩(wěn)定導致了這樣的問題。
Maven，已經(jīng)替我們想好了解決方案，就是使用Snapshot版本，在開發(fā)過程中B發(fā)布的版本標志為Snapshot版本，A進行依賴的時候選擇Snapshot版本，那么每次B發(fā)布的話，會在私服倉庫中，形成帶有時間戳的Sn[圖片上傳中...(image.png-107d99-1575173093654-0)]
apshot版本，而A構建的時候會自動下載B最新時間戳的Snapshot版本！
如何解決版本沖突
依賴的版本？
首先來說，對于Maven而言，同一個groupId同一個artifactId下，只能使用一個version！
根據(jù)上圖的依賴順序，將使用1.2版本的jar。
現(xiàn)在，我們可以思考下了，比如工程中需要引入A、B，而A依賴1.0版本的C，B依賴2.0版本的C，那么問題來了，C使用的版本將由引入A、B的順序而定？這顯然不靠譜！如果A的依賴寫在B的依賴后面，將意味著最后引入的是1.0版本的C，很可能在運行階段出現(xiàn)類（ClassNotFoundException）、方法（NoSuchMethodError）找不到的錯誤（因為B使用的是高版本的C）！
這里其實涉及到了2個概念：依賴傳遞（transitive）、Maven的最近依賴策略。
依賴傳遞：如果A依賴B，B依賴C，那么引入A，意味著B和C都會被引入。
Maven的最近依賴策略：如果一個項目依賴相同的groupId、artifactId的多個版本，那么在依賴樹（mvn dependency:tree）中離項目最近的那個版本將會被使用。（從這里可以看出Maven是不是有點小問題呢？能不能選擇高版本的進行依賴么？據(jù)了解，Gradle就是version+策略）
現(xiàn)在，我們可以想想如何處理依賴沖突呢？
想法1：要使用哪個版本，我們是清楚的，那么能不能不管如何依賴傳遞，都可以進行版本鎖定呢？
使用<dependencyManagement> 來實現(xiàn)維護所有子模塊版本的一致性。
想法2：在依賴傳遞中，能不能去掉我們不想依賴的？
使用<exclusions> [在實際中我們可以在IDEA中直接利用插件幫助我們生成]
想法3：既然是最近依賴策略，那么我們就直接使用顯式依賴指定版本，那不就是最靠近項目的么？Maven繼承與聚合，這個你需要掌握。
想法4：引入依賴的最佳實踐，提前發(fā)現(xiàn)問題
在工程中，我們避免不了需要加一些依賴，也許加了依賴后運行時才發(fā)現(xiàn)存在依賴沖突在去解決，似乎有點晚！那么能不能提前發(fā)現(xiàn)問題呢？
如果我們新加入一個依賴的話，那么先通過mvn dependency:tree命令形成依賴樹，看看我們新加入的依賴，是否存在傳遞依賴，傳遞依賴中是否和依賴樹中的版本存在沖突，如果存在多個版本沖突，利用上文的方式進行解決！
