第1篇：Maven入門
maven系列目標：從入門開始開始掌握一個高階開發所需要的maven技能。
這是maven系列第1篇。
為什麼我們要學習maven?
學習某些技術，肯定是我們遇到了某些問題，而這些問題目前手頭上沒有很好的方案去解決，此時剛好有一種技術可以很好的解決這個問題，這樣能夠驅動我們願意去學。所以我們學任何技術之前，需要先了解這種技術能夠解決什麼問題。帶著問題去學習，大家才有興趣，才能夠更快的掌握。
我們遇到了什麼問題呢？
maven還未出世的時候，我們有很多痛苦的經歷。
痛點1：jar包難以尋找
比如我們專案中需要用到fastjson，此時我們會去百度上檢索fastjson相關jar包，然後下載下來，放到專案的lib下面，然後加到專案的classpath下面，用著用著發現這個jar的版本太老了，不是我們想要的，然後又重新去找，痛苦啊。
痛點2：jar包依賴的問題
jar包一般都不是獨立存在的，一般一些jar也會用到其他的jar，比如spring-aop。jar會用到spring-core。jar，這種依賴可能比較簡單，有些依賴可能有很多級，比如a。jar依賴於b。jar，而b。jar依賴c。jar，而c。jar又依賴於b。jar，當你用到a。jar的時候，你需要把其他3個也進入才可以，所以你用到一個jar的時候，你必須明確知道這些jar還會依賴於哪些jar，把他們都引入進來，否則專案是無法正常執行的，當專案用到很多jar的時候，我們是很難判斷缺少哪些jar的，只有在專案執行過程報錯了，才知道，這種也是相當痛苦的，浪費了大量時間。
痛點3：jar包版本衝突問題
專案中用到了a。jar，a。jar依賴於c。jar的1。5版本，然後我們把這2個jar複製到專案中，後面又用到了b。jar，但是b。jar又依賴於c。jar的1。0版本，此時你把b。jar和c-1。0。jar引進來了，會發現c。jar有2個版本，發生衝突了，啟動的時候會報錯，這種情況你要著手去解決jar衝突的問題，也是非常痛苦的。
當我們從網上找到一個jar包來使用的時候，我們是很難判斷這個jar依賴的其他jar的版本的，比如a。jar依賴於b。jar，你從網上把b。jar找到了，最後放入專案中，發現b。jar的版本太老了，又得去重新找。
記得之前在第三方支付工作的時候，我記憶猶新，當時用到的是lvy來引入jar的，這玩意解決jar包的衝突沒有什麼好辦法，為了解決專案中jar包衝突的問題，花了整整一週時間。
痛點4：jar不方便管理
當我們的專案比較大的時候，我們會將一個大的專案分成很多小的專案，每個小專案由幾個開發負責，比如一個電商專案分為：賬戶相關的專案、訂單相關的專案、商品相關的專案，這些專案的結構都是類似的，用到的技術都是一樣的：ssh（spring、springmvc、mybatis），然後每個專案都需要把這些jar複製一份到自己的專案目錄中，最後10個專案只是jar就複製了10份，後來，我們發現專案中有些jar需要升級版本，打算替換一下，此時我們需要依次去替換10個專案，也是相當痛苦。
痛點5：專案結構五花八門
很久之前，我們使用eclipse搭建一個專案的時候，java原始碼的位置、資原始檔的位置、測試檔案的位置、靜態資源位置、編譯之後的class檔案位置，都是可以隨意放的，這些是由各自公司的架構師搭建專案時定好的，根據他們的經驗來定義的，導致每個公司可能專案結構都不太一樣，來新人之後，看到專案結構一臉懵逼，根本不知道哪是哪，需要人指導，無形的增加了成本，如果大家都按照某種規範採用同一種專案結構，這樣豈不是很方便麼，大家按照某種約定，專案使用同樣的結構，比如：java檔案、資原始檔、測試用例、靜態資源、編譯之後的class、打包之後jar的位置等等各種檔案的位置，這些東西，如果所有做java開發的公司都約定好的，這樣拿到一個專案之後，就可以省去很多事情了。
痛點6：專案的生命週期控制方式五花八門
一個專案對於開發來說，生命週期是這樣的：搭建專案結構、編碼、跑測試用例、編譯、打包、釋出到環境測試、釋出到生產環境。其中除了編碼之外，大多數時間都是在編譯、打包、釋出到測試環境，然後測試開始測試，測試提出bug，開發接著修改bug，之後又進行自測、編譯、打包、釋出到測試環境，多數時間都在重複著跑單元測試、編譯、打包、釋出的工作。在沒有自動化編譯的時候，每個過程都需要我們手動去操作，可能有些開發比較優秀，將這些操作寫出自動化的指令碼來進行了，但是每個人寫的自動化的指令碼可能都是不一樣的，有些用java寫，有些人用shell寫等等。
後面有了Ant，ant可以將執行測試用例、編譯、打包、釋出搞成自動化的，ant自由度比較高，需要自己去寫很多配置，比如編譯：需要指定原始碼位於什麼地方，編譯之後的檔案放在什麼地方。ant的靈活度比極高，細節都交給了開發者自己去控制了，每個人寫出來的ant指令碼也是各種各樣的，不利於大家統一維護和接受。
像上面這些過程，幾乎是所有java專案都需要經歷的，屬於高頻必備的操作，如果全世界所有開發java的能夠約定好java專案的結構，測試用例存放的位置，編譯之後的class存放的位置、打包之後檔案存放的位置，自動化指令碼都是用同一種規範來開發，那麼大家最終寫的自動化釋出的指令碼都是類似的，只是最後釋出的地址不一樣，其他都是一樣的，這樣的指令碼會簡化很多，新人來了上手也非常快。
Maven是什麼呢？
maven就是解決上面所有痛點的神器，算是所有開發者的福音。
使用maven搭建的專案架構，都需要遵循同樣的結構，java原始檔、資原始檔、測試用例類檔案、靜態資原始檔這些都是約定好的，大家都按照這個約定來，所以如果你們的專案是使用maven建立的，招新人來接手，如果他們懂maven，根本不需要培訓，上來就可以看懂整個專案的結構。
maven給每個jar定義了唯一的標誌，這個在maven中叫做專案的座標，透過這個座標可以找到你需要用到的任何版本的jar包。
maven會自動解決jar依賴的問題，比如你用到了a-1。0。jar，而a-1。0。jar依賴於b-1。1。jar和c-1。5。jar，當我們透過maven把a-1。0。jar引入之後，b-1。1。jar和c-1。5。jar會自動被引入進來。
maven可以很容易的解決不同版本之間的jar衝突的問題。
maven使開發者更加方便的控制整個專案的生命週期，比如：
mvn clear 可以清理上次已編譯好的程式碼mvn compile 可以自動編譯專案mvn test 可以自動執行所有測試用例mvn package 可以完成打包需要的所有操作（自動包含了清理、編譯、測試的過程）
還有更多更多好用的操作，由於maven使所有專案結構都是約定好的，所以這些操作都被簡化為了非常簡單的命令。
我們自己開發了一些工具包，需要給其他人使用時，只需要一個簡單的mvn install命令就可以公佈出去了，然後將這個jar的座標告知使用者，使用者就可以找到了，根本不需要你將jar包傳輸給他。
由於maven專案結構都是約定好的，所以非常方便擴充套件，上面說的各種maven命令都是以外掛的形式整合進來的，如果你願意，你也可以自己開發一些maven外掛給其他人使用，比如阿里內部自己開發的外掛自動將專案釋出到阿里雲上面，非常方便開發釋出專案。
再來看一下官方解釋什麼是maven：
maven是apache軟體基金會組織維護的一款自動化構建工具，專注服務於java平臺的專案構建和依賴管理
。
下篇我們將介紹maven的使用。
