Maven筆記 - 第一章

第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  可以完成打包需要的所有操作(自動包含了清理、編譯、測試的過程)
           

還有更多更多好用的操作，由于maven使所有項目結構都是約定好的，是以這些操作都被簡化為了非常簡單的指令。

我們自己開發了一些工具包，需要給其他人使用時，隻需要一個簡單的

mvn install

指令就可以公布出去了，然後将這個jar的坐标告知使用者，使用者就可以找到了，根本不需要你将jar包傳輸給他。

由于maven項目結構都是約定好的，是以非常友善擴充，上面說的各種maven指令都是以插件的形式內建進來的，如果你願意，你也可以自己開發一些maven插件給其他人使用，比如阿裡内部自己開發的插件自動将項目釋出到阿裡雲上面，非常友善開發釋出項目。

再來看一下官方解釋什麼是maven：maven是apache軟體基金會組織維護的一款自動化建構工具，專注服務于java平台的項目建構和依賴管理。

下篇我們将介紹maven的使用。