Maven在日常應該是用得挺多的，畢竟我們都需要打包發布上線的嘛，但是剛畢業的時候可沒有這個概念。
我們肯定是知道Maven能管理我們的項目，但是在學習的時候往往只用到Maven來導入各種的依賴。
我們肯定是知道Maven是有對應的倉庫，然后我們配置了國內的Maven倉庫來讓jar包下載得更快。
我們可能會用Maven來編譯自己的項目，本地打好package，然后將項目在本地啟動起來。如果我們有一臺機器的服務器，打完包以后就將本地的war包手動上傳到自己的服務器上啟動。
我們可能會知道Maven可以配置自己的倉庫（私有倉庫），可能會搭建過，但是又有哪幾個人將自己的jar包發布到私有的倉庫呢？
去到公司里邊，公司一般也有自己的私有倉庫，我們寫的系統可能會被各個團隊使用的，所以我們會把寫好的包打到私有倉庫上。常用到的Maven命令其實不會很多，一般就是以下的幾個：
1、mvn compile
2、mvn test
3、mvn clean
4、mvn pakage
5、mvn install
6、mvn deploy
7、mvn versions:set -DnewVersion=xxxx 設置Maven的版本
8、mvn dependency:tree 查看maven的依賴樹（排查依賴很有效）
常用參數
-Dmaven.test.skip=true
-Dmaven.JAVAdoc.skip=true
直接從網上摘錄以下package、install、deploy的區別：
- package命令完成了項目編譯、單元測試、打包功能，但沒有把打好的可執行jar包（war包或其它形式的包）部署到本地maven倉庫和遠程maven私服倉庫
- install命令完成了項目編譯、單元測試、打包功能，同時把打好的可執行jar包（war包或其它形式的包）布署到本地maven倉庫，但沒有布署到遠程maven私服倉庫
- deploy命令完成了項目編譯、單元測試、打包功能，同時把打好的可執行jar包（war包或其它形式的包）部署到本地maven倉庫和遠程maven私服倉庫
一個工程下一般也會有多個Module，我們會用父工程的pom.xml來管理我們的jar包版本，在子Module引用父工程的就好了。
別傻乎乎地就將各種jar包的版本到子Module下寫，雖然jar包是肯定能導入進去了，但是這樣做不規范。
下面簡單體驗幾個最常用的命令（建議自己實操一下）
mvn compile -Dmaven.test.skip=true，這個命令會把我們的代碼編譯，編譯完我們如果使用IDEA就可以發現有target目錄
mvn package -Dmaven.test.skip=true就可以幫我們打包。
三歪一次不可描述的經歷
最近三歪在整合系統，把一些零散的系統整合到一個系統里邊，所以一個系統會出現多個Module。之前項目也是多個Module的，只是沒有現在的多，比如下面的圖
從上面的圖我們可以看到在父工程下有幾個配置文件，分別是dev/local/online/pre。很明顯地，我們不同的環境下，配置應該是不一樣的。
這應該很好理解，我們線上的服務器配置信息和測試環境的配置信息怎么可能相同嘛，所以各個環境的配置是分開的。
因為要做合并的事，我就把一些系統合并到父工程里邊去。所以我會在父工程下新建Module，然后把代碼拷貝進去。顯然，每個工程可能都會有相應的配置，然后配置也是區分環境的嘛。
比如下面的圖（sanwai.name這份配置由各個環境下的配置所去讀取）：
我在各個環境下的配置文件都寫好了sanwai.name的值了
等我一切寫完的時候，我發現服務一直啟動不起來，始終沒有讀到我在dev/local/pre/online配置的值。我就很懷疑了，明明我配置了呀。
Spring的property-placeholder我明明都已經寫好了，路徑都沒有任何問題，在本地都能直接「點」去跳轉到對應的配置文件了。這咋回事啊
<context:property-placeholder
ignore-unresolvable="true" ignore-resource-not-found="true"
location="classpath*:core-config.properties" />
于是，我花了很長的一段時間上看我的property-placeholder是不是有問題，是不是我哪里的使用姿勢不對。
最后實在忍不住了，問了一下同事有沒有遇到過這個坑，然后同事告訴我：分環境讀取配置不是Spring的功能，是Maven
我：？？？？然后在內網搜了一下，還真的是。大概看了一下，其實就是用到了Maven的profile功能。
后來在pom文件下指定讀取對應的配置文件路徑，就可以了。
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering><!-- 是否使用過濾器 -->
</resource>
</resources>
</build>
其實就是在打包的時候去指定不同的環境，從而生成一份正確的配置文件。
mvn clean package -DskipTests -Ptest // 指定的是test環境
那么按道理，只要我發布上線過代碼，就應該知道有這么一個東西啊。
我司有自己的一套發布系統，把很多的細節都給屏蔽掉了（無論是Git還是Maven的細節都屏蔽了很多）。壓根就不需要自己去打命令去創建Git分支，去合并master分支，去敲maven的命令打包。
最后在這里推薦一本Maven實戰文檔
本書適合所有Java程序員閱讀。由于自動化構建，依賴管理等問題并不只存在于Java世界，因此非Java 程序員也能夠從該書中獲益。無論你是從未接觸過Maven、還是已經用了Meven很長時間，亦或者想要擴展Maven,都能從本書獲得有價值的參考建議。
其次，本書也適合項目經理閱讀，它能幫助你更規范、更高效地管理Java項目。
第1章對Maven做了簡要介紹，通過-些程序員熟悉的例子介紹了Maven 是什么，為.什么需要Maven.建議所有讀者都閱讀以獲得一個大局的印象。
第2-3章是對Maven的一個人門介紹，這些內容對初學者很有幫助，如果你已經比較熟悉Maven,可以跳過。
第4章介紹了本書使用的背景案例，后面的很多章節都會基于該案例展開，因此建議讀者至少簡單瀏覽一遍。
第5-8章深人闡述了Maven 的核心概念，包括坐標，依賴、倉庫。生命周期、插件，繼承和多模塊聚合，等等，每個知識點都有實際的案例相佐，建議讀者仔細閱讀。
第9章介紹使用Nexus建立私服，如果你要在實際工.作中使用Maven,這是必不可少的。
第10-16章介紹了一些相對高級且離散的知識點,包括測試，持續集成與Hudon, Web項目與自動化部署、自動化版本管理、智能適應環境差異的靈活構建、站點生成，以及Maven的Eelipse插件m2elipe,等等。讀者可以根據自己實際需要和興趣選擇性地閱讀。
第17-18章介紹了如何編寫Archeype和Maven插件。一般的Maven用戶在實際工作中往往不需要接觸這些知識，如果你需要編寫插件擴展Maven,或者需要編寫Archetype維護自己的項目骨架以方便團隊開發，那么可以仔細閱讀這兩章的內容。
