【Maven】總結

阿新 • • 發佈：2020-07-14

導言：生產環境下開發不再是一個專案一個工程，而是每一個模組建立一個工程，而多個模組整合在一起就需要
使用到像 Maven 這樣的構建工具。

1 Why?

1.1 真的需要嗎？

Maven 是幹什麼用的？這是很多同學在剛開始接觸 Maven 時最大的問題。之所以會提出這個問題，
是因為即使不使用 Maven 我們仍然可以進行 B/S 結構專案的開發。從表述層、業務邏輯層到持久化層
再到資料庫都有成熟的解決方案——不使用 Maven 我們一樣可以開發專案啊？

這裡給大家糾正一個誤區，Maven 並不是直接用來輔助編碼的，它戰鬥的崗位並不是以上各層。所
以我們有必要通過企業開發中的實際需求來看一看哪些方面是我們現有技術的不足。

1.2 究竟為什麼？

為什麼要使用 Maven？它能幫助我們解決什麼問題？

①新增第三方 jar 包
在今天的 JavaEE 開發領域，有大量的第三方框架和工具可以供我們使用。要使用這些 jar 包最簡單的方法就是複製貼上到 WEB-INF/lib 目錄下。但是這會導致每次建立一個新的工程就需要將 jar 包重複複製到 lib 錄下，從而造成工作區中存在大量重複的檔案，讓我們的工程顯得很臃腫。
而使用 Maven 後每個 jar 包本身只在本地倉庫中儲存一份，需要 jar 包的工程只需要以座標的方式簡單的引用一下就可以了。不僅極大的節約了儲存空間，讓專案更輕巧，更避免了重複檔案太多而造成的混亂。
②jar 包之間的依賴關係
jar 包往往不是孤立存在的，很多 jar 包都需要在其他 jar 包的支援下才能夠正常工作，我們稱之為 jar 包之間的依賴關係。最典型的例子是：commons-fileupload-1.3.jar 依賴於 commons-io-2.0.1.jar，如果沒有 IO 包，FileUpload 包就不能正常工作。
那麼問題來了，你知道你所使用的所有 jar 包的依賴關係嗎？當你拿到一個新的從未使用過的 jar 包，你如何得知他需要哪些 jar 包的支援呢？如果不瞭解這個情況，匯入的 jar 包不夠，那麼現有的程式將不能正常工作。再進一步，當你的專案中需要用到上百個 jar 包時，你還會人為的，手工的逐一確認它們依賴的其他 jar 包嗎？這簡直是不可想象的。

而引入 Maven 後，Maven 就可以替我們自動的將當前 jar 包所依賴的其他所有 jar 包全部匯入進來，無需人工參與，節約了我們大量的時間和精力。用實際例子來說明就是：通過 Maven 匯入 commons-fileupload-1.3.jar 後，commons-io-2.0.1.jar 會被自動匯入，程式設計師不必瞭解這個依賴關係。
下圖是 Spring 所需 jar 包的部分依賴關係
③獲取第三方 jar 包
JavaEE 開發中需要使用到的 jar 包種類繁多，幾乎每個 jar 包在其本身的官網上的獲取方式都不盡相同。為了查詢一個 jar 包找遍網際網路，身心俱疲，沒有經歷過的人或許體會不到這種折磨。不僅如此，費勁心血找的 jar 包裡有的時候並沒有你需要的那個類，又或者又同名的類沒有你要的方法——以不規範的方式獲取的 jar 包也往往是不規範的。
使用 Maven 我們可以享受到一個完全統一規範的 jar 包管理體系。你只需要在你的專案中以座標的方式依賴一個 jar 包，Maven 就會自動從中央倉庫進行下載，並同時下載這個 jar 包所依賴的其他 jar 包——規範、完整、準確！一次性解決所有問題！

Tips：在這裡我們順便說一下，統一的規範幾乎可以說成是程式設計師的最高信仰。如果沒有統一的規範，就意味著每個具體的技術都各自為政，需要以諸多不同的特殊的方式加入到專案中；好不容易加入進來還會和其他技術格格不入，最終受苦的是我們。而任何一個領域的統一規範都能夠極大的降低程式設計師的工作難度，減少工作量。
例如：USB 介面可以外接各種裝置，如果每個裝置都有自己獨特的介面，那麼不僅製造商需要維護各個介面的設計方案，使用者也需要詳細瞭解每個裝置對應的介面，無疑是非常繁瑣的。
④將專案拆分成多個工程模組
隨著 JavaEE 專案的規模越來越龐大，開發團隊的規模也與日俱增。一個專案上千人的團隊持續開發很多年對於 JavaEE 專案來說再正常不過。那麼我們想象一下：幾百上千的人開發的專案是同一個 Web 工程。那麼架構師、專案經理該如何劃分專案的模組、如何分工呢？這麼大的專案已經不可能通過 package 結構來劃分模組，必須將專案拆分成多個工程協同開發。多個模組工程中有的是 Java 工程，有的是 Web 工程。
那麼工程拆分後又如何進行互相呼叫和訪問呢？這就需要用到 Maven 的依賴管理機制。大家請看我們的 Survey 調查專案拆分的情況：

上層模組依賴下層，所以下層模組中定義的 API 都可以為上層所呼叫和訪問。

2 What?

2.1 Maven 簡介

Maven 是 Apache 軟體基金會組織維護的一款自動化構建工具，專注服務於 Java 平臺的專案構建和依賴管理。Maven 這個單詞的本意是：專家，內行。讀音是['meɪv(ə)n]或['mevn]。

2.2 什麼是構建

構建並不是建立，建立一個工程並不等於構建一個專案。要了解構建的含義我們應該由淺入深的從以下三個層面來看：

①純 Java 程式碼
大家都知道，我們 Java 是一門編譯型語言，.java 副檔名的原始檔需要編譯成.class 副檔名的位元組碼檔案才能夠執行。所以編寫任何 Java 程式碼想要執行的話就必須經過編譯得到對應的.class 檔案。
②Web 工程
當我們需要通過瀏覽器訪問 Java 程式時就必須將包含 Java 程式的 Web 工程編譯的結果“拿”到伺服器上的指定目錄下，並啟動伺服器才行。這個“拿”的過程我們叫部署。
我們可以將未編譯的 Web 工程比喻為一隻生的雞，編譯好的 Web 工程是一隻煮熟的雞，編譯部署的過程就是將雞燉熟。
Web 工程和其編譯結果的目錄結構對比見下圖：
③實際專案
在實際專案中整合第三方框架，Web 工程中除了 Java 程式和 JSP 頁面、圖片等靜態資源之外，還包括第三方框架的 jar 包以及各種各樣的配置檔案。所有這些資源都必須按照正確的目錄結構部署到伺服器上，專案才可以執行。
所以綜上所述：構建就是以我們編寫的 Java 程式碼、框架配置檔案、國際化等其他資原始檔、JSP 頁面和圖片等靜態資源作為“原材料”，去“生產”出一個可以執行的專案的過程。
那麼專案構建的全過程中都包含哪些環節呢？

2.3 構建過程的幾個主要環節

①清理：刪除以前的編譯結果，為重新編譯做好準備。
②編譯：將 Java 源程式編譯為位元組碼檔案。
③測試：針對專案中的關鍵點進行測試，確保專案在迭代開發過程中關鍵點的正確性。
④報告：在每一次測試後以標準的格式記錄和展示測試結果。
⑤打包：將一個包含諸多檔案的工程封裝為一個壓縮檔案用於安裝或部署。Java 工程對應 jar 包，Web 工程對應 war 包。
⑥安裝：在 Maven 環境下特指將打包的結果——jar 包或 war 包安裝到本地倉庫中。
⑦部署：將打包的結果部署到遠端倉庫或將 war 包部署到伺服器上執行。

2.4 自動化構建

其實上述環節我們在 Eclipse 中都可以找到對應的操作，只是不太標準。那麼既然 IDE 已經可以進
行構建了我們為什麼還要使用 Maven 這樣的構建工具呢？我們來看一個小故事：

這是陽光明媚的一天。託馬斯嚮往常一樣早早的來到了公司，衝好一杯咖啡，進入了自己的郵箱——很不幸，QA 小組發來了一封郵件，報告了他昨天提交的模組的測試結果——有 BUG。“好吧，反正也不是第一次”，託馬斯搖搖頭，進入 IDE，執行自己的程式，編譯、打包、部署到伺服器上，然後按照郵件中的操作路徑進行測試。“嗯，沒錯，這個地方確實有問題”，託馬斯說道。於是託馬斯開始嘗試修復這個 BUG，當他差不多有眉目的時候已經到了午飯時間。
下午繼續工作。BUG 很快被修正了，接著託馬斯對模組重新進行了編譯、打包、部署，測試之後確認沒有問題了，回覆了 QA 小組的郵件。
一天就這樣過去了，明媚的陽光化作了美麗的晚霞，託馬斯卻覺得生活並不像晚霞那樣美好啊。

讓我們來梳理一下託馬斯這一天中的工作內容

從中我們發現，託馬斯的很大一部分時間花在了“編譯、打包、部署、測試”這些程式化的工作上面，而真正需要由“人”的智慧實現的分析問題和編碼卻只佔了很少一部分。

能否將這些程式化的工作交給機器自動完成呢？——當然可以！這就是自動化構建。

此時 Maven 的意義就體現出來了，它可以自動的從構建過程的起點一直執行到終點：

2.5 Maven 核心概念

Maven 能夠實現自動化構建是和它的內部原理分不開的，這裡我們從 Maven 的九個核心概念入手，看看 Maven 是如何實現自動化構建的

①POM
②約定的目錄結構
③座標
④依賴管理
⑤倉庫管理
⑥生命週期
⑦外掛和目標
⑧繼承
⑨聚合

3 How?

Maven 的核心程式中僅僅定義了抽象的生命週期，而具體的操作則是由 Maven 的外掛來完成的。可是 Maven 的外掛並不包含在 Maven 的核心程式中，在首次使用時需要聯網下載。
下載得到的外掛會被儲存到本地倉庫中。本地倉庫預設的位置是：~.m2\repository。
如果不能聯網可以使用我們提供的 RepMaven.zip 解壓得到。具體操作參見“Maven 操作指南.txt”。

4 約定的目錄結構

約定的目錄結構對於 Maven 實現自動化構建而言是必不可少的一環，就拿自動編譯來說，Maven 必須
能找到 Java 原始檔，下一步才能編譯，而編譯之後也必須有一個準確的位置保持編譯得到的位元組碼檔案。
我們在開發中如果需要讓第三方工具或框架知道我們自己建立的資源在哪，那麼基本上就是兩種方式：

①通過配置的形式明確告訴它
②基於第三方工具或框架的約定

Maven 對工程目錄結構的要求就屬於後面的一種。

現在 JavaEE 開發領域普遍認同一個觀點：約定 > 配置 > 編碼。意思就是能用配置解決的問題就不編碼，
能基於約定的就不進行配置。而 Maven 正是因為指定了特定檔案儲存的目錄才能夠對我們的 Java 工程進行
自動化構建。

5 POM

Project Object Model：專案物件模型。將 Java 工程的相關資訊封裝為物件作為便於操作和管理的模型。Maven 工程的核心配置。可以說學習 Maven 就是學習 pom.xml 檔案中的配置。

6 座標

6.1 幾何中的座標

[1]在一個平面中使用 x、y 兩個向量可以唯一的確定平面中的一個點。
[2]在空間中使用 x、y、z 三個向量可以唯一的確定空間中的一個點。

6.2 Maven 的座標

使用如下三個向量在 Maven 的倉庫中唯一的確定一個 Maven 工程。

[1]groupid：公司或組織的域名倒序+當前專案名稱
[2]artifactId：當前專案的模組名稱
[3]version：當前模組的版本

<groupId>com.atguigu.maven</groupId>

<artifactId>Hello</artifactId>

<version>0.0.1-SNAPSHOT</version>

6.3 如何通過座標到倉庫中查詢 jar 包？

[1]將 gav 三個向量連起來
com.atguigu.maven+Hello+0.0.1-SNAPSHOT
[2]以連起來的字串作為目錄結構到倉庫中查詢
com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

※注意：我們自己的 Maven 工程必須執行安裝操作才會進入倉庫。安裝的命令是：mvn install

7 依賴

Maven 中最關鍵的部分，我們使用 Maven 最主要的就是使用它的依賴管理功能。要理解和掌握 Maven 的依賴管理，我們只需要解決一下幾個問題：

①依賴的目的是什麼
當 A jar 包用到了 B jar 包中的某些類時，A 就對 B 產生了依賴，這是概念上的描述。那麼如何在專案中以依賴的方式引入一個我們需要的 jar 包呢？
答案非常簡單，就是使用 dependency 標籤指定被依賴 jar 包的座標就可以了。
```
<dependency>

  <groupId>com.atguigu.maven</groupId>

  <artifactId>Hello</artifactId>

  <version>0.0.1-SNAPSHOT</version>

  <scope>compile</scope>

</dependency>
```
②依賴的範圍
大家注意到上面的依賴資訊中除了目標 jar 包的座標還有一個 scope 設定，這是依賴的範圍。依賴的範圍有幾個可選值，我們用得到的是：compile、test、provided 三個。
1. [1]從專案結構角度理解 compile 和 test 的區別
  
  結合具體例子：對於 HelloFriend 來說，Hello 就是服務於主程式的，junit 是服務於測試程式的。
  HelloFriend 主程式需要 Hello 是非常明顯的，測試程式由於要呼叫主程式所以也需要 Hello，所以 compile 範圍依賴對主程式和測試程式都應該有效。
  HelloFriend 的測試程式部分需要 junit 也是非常明顯的，而主程式是不需要的，所以 test 範圍依賴僅僅對於主程式有效。
2. [2]從開發和執行這兩個不同階段理解 compile 和 provided 的區別
3. [3]有效性總結
  
  compile test provided
  
  主程式 √ × √
  
  測試程式 √ √ √
  
  參與部署 √ × ×
③依賴的傳遞性
A 依賴 B，B 依賴 C，A 能否使用 C 呢？那要看 B 依賴 C 的範圍是不是 compile，如果是則可用，否則不
可用。

Maven 工程依賴範圍對 A 的可見性

C compile √

D test ×

E provided ×

	compile	test	provided
主程式	√	×	√
測試程式	√	√	√
參與部署	√	×	×

Maven 工程	依賴範圍	對 A 的可見性
C	compile	√
D	test	×
E	provided	×

④依賴的排除
如果我們在當前工程中引入了一個依賴是 A，而 A 又依賴了 B，那麼 Maven 會自動將 A 依賴的 B 引入當前工程，但是個別情況下 B 有可能是一個不穩定版，或對當前工程有不良影響。這時我們可以在引入 A 的時候將 B 排除。

[1]情景舉例

[2]配置方式

<dependency>

  <groupId>com.atguigu.maven</groupId>

  <artifactId>HelloFriend</artifactId>

  <version>0.0.1-SNAPSHOT</version>

  <type>jar</type>

  <scope>compile</scope>

  <exclusions>

    <exclusion>

      <groupId>commons-logging</groupId>

      <artifactId>commons-logging</artifactId>

    </exclusion>

  </exclusions>

</dependency>

[3]排除後的效果

⑤統一管理所依賴 jar 包的版本
對同一個框架的一組 jar 包最好使用相同的版本。為了方便升級框架，可以將 jar 包的版本資訊統一提取出來

[1]統一宣告版本號

<properties>

  <atguigu.spring.version>4.1.1.RELEASE</atguigu.spring.version>

</properties>

其中 atguigu.spring.version 部分是自定義標籤。

[2]引用前面宣告的版本號

<dependencies>

  <dependency>

    <groupId>org.springframework</groupId>

    <artifactId>spring-core</artifactId>

    <version>${atguigu.spring.version}</version>

  </dependency>

  ……

</dependencies>

[3]其他用法

<properties>

  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

⑥依賴的原則：解決 jar 包衝突
1. [1]路徑最短者優先
2. [2]路徑相同時先宣告者優先
  
  這裡“宣告”的先後順序指的是 dependency 標籤配置的先後順序。

8 倉庫

8.1 分類

[1]本地倉庫：為當前本機電腦上的所有 Maven 工程服務。
[2]遠端倉庫
1. (1)私服：架設在當前區域網環境下，為當前區域網範圍內的所有 Maven 工程服務。
2. (2)中央倉庫：架設在 Internet 上，為全世界所有 Maven 工程服務。
3. (3)中央倉庫的映象：架設在各個大洲，為中央倉庫分擔流量。減輕中央倉庫的壓力，同時更快的響應使用者請求。

8.2 倉庫中的檔案

[1]Maven 的外掛
[2]我們自己開發的專案的模組
[3]第三方框架或工具的 jar 包

※不管是什麼樣的 jar 包，在倉庫中都是按照座標生成目錄結構，所以可以通過統一的方式查詢或依賴。

9 生命週期

9.1 什麼是 Maven 的生命週期？

Maven 生命週期定義了各個構建環節的執行順序，有了這個清單，Maven 就可以自動化的執行構建命令了。
Maven 有三套相互獨立的生命週期，分別是：
1. ①Clean Lifecycle 在進行真正的構建之前進行一些清理工作。
2. ②Default Lifecycle 構建的核心部分，編譯，測試，打包，安裝，部署等等。
3. ③Site Lifecycle 生成專案報告，站點，釋出站點。

它們是相互獨立的，你可以僅僅呼叫 clean 來清理工作目錄，僅僅呼叫 site 來生成站點。當然你也可以直接執行 mvn clean install site 執行所有這三套生命週期。

每套生命週期都由一組階段(Phase)組成，我們平時在命令列輸入的命令總會對應於一個特定的階段。比如，執行 mvn clean，這個 clean 是 Clean 生命週期的一個階段。有 Clean 生命週期，也有 clean 階段。

9.2 Clean 生命週期

Clean 生命週期一共包含了三個階段：

①pre-clean：執行一些需要在 clean 之前完成的工作
②clean：移除所有上一次構建生成的檔案
③post-clean：執行一些需要在 clean 之後立刻完成的工作

9.3 Site 生命週期

①pre-site：執行一些需要在生成站點檔案之前完成的工作
②site：生成專案的站點檔案
③post-site：執行一些需要在生成站點檔案之後完成的工作，並且為部署做準備
④site-deploy：將生成的站點檔案部署到特定的伺服器上

這裡經常用到的是 site 階段和 site-deploy 階段，用以生成和釋出 Maven 站點，這可是 Maven 相當強大的功能，Manager 比較喜歡，檔案及統計資料自動生成，很好看。

9.4 Default 生命週期

Default 生命週期是 Maven 生命週期中最重要的一個，絕大部分工作都發生在這個生命週期中。這裡，只解釋一些比較重要和常用的階段：

validate
generate-sources
process-sources
generate-resources
process-resources 複製並處理資原始檔，至目標目錄，準備打包。
compile 編譯專案的原始碼。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 複製並處理資原始檔，至目標測試目錄。
test-compile 編譯測試原始碼。
process-test-classes
test 使用合適的單元測試框架執行測試。這些測試程式碼不會被打包或部署。
prepare-package
package 接受編譯好的程式碼，打包成可釋出的格式，如 JAR。
pre-integration-test
integration-test
post-integration-test
verify
install 將包安裝至本地倉庫，以讓其它專案依賴。
deploy 將最終的包複製到遠端的倉庫，以讓其它開發人員與專案共享或部署到伺服器上執行。

9.5 生命週期與自動化構建

執行任何一個階段的時候，它前面的所有階段都會被執行，例如我們執行 mvn install 的時候，程式碼會被編譯，測試，打包。這就是 Maven 為什麼能夠自動執行構建過程的各個環節的原因。此外，Maven 的外掛機制是完全依賴 Maven 的生命週期的，因此理解生命週期至關重要。

10 外掛和目標

Maven 的核心僅僅定義了抽象的生命週期，具體的任務都是交由外掛完成的。
每個外掛都能實現多個功能，每個功能就是一個外掛目標。
Maven 的生命週期與外掛目標相互繫結，以完成某個具體的構建任務。

例如：compile 就是外掛 maven-compiler-plugin 的一個目標；pre-clean 是外掛 maven-clean-plugin 的一個目標。

11 繼承

11.1 為什麼需要繼承機制？

由於非 compile 範圍的依賴資訊是不能在“依賴鏈”中傳遞的，所以有需要的工程只能單獨配置。例如：

Hello

<dependency>

  <groupId>junit</groupId>

  <artifactId>junit</artifactId>

  <version>4.0</version>

  <scope>test</scope>

</dependency>

HelloFriend

<dependency>

  <groupId>junit</groupId>

  <artifactId>junit</artifactId>

  <version>4.0</version>

  <scope>test</scope>

</dependency>

MakeFriend

<dependency>

  <groupId>junit</groupId>

  <artifactId>junit</artifactId>

  <version>4.0</version>

  <scope>test</scope>

</dependency>

此時如果專案需要將各個模組的junit版本統一為4.9，那麼到各個工程中手動修改無疑是非常不可取的。使用繼承機制就可以將這樣的依賴資訊統一提取到父工程模組中進行統一管理。

11.2 建立父工程

建立父工程和建立一般的 Java 工程操作一致，唯一需要注意的是：打包方式處要設定為 pom。

11.3 在子工程中引用父工程

<parent>

  <!-- 父工程座標 -->

  <groupId>...</groupId>

  <artifactId>...</artifactId>

  <version>...</version>

  <relativePath>從當前目錄到父專案的 pom.xml 檔案的相對路徑</relativePath>

</parent>

<parent>

  <groupId>com.atguigu.maven</groupId>

  <artifactId>Parent</artifactId>

  <version>0.0.1-SNAPSHOT</version>

  <!-- 指定從當前子工程的pom.xml檔案出發，查詢父工程的pom.xml的路徑 -->

  <relativePath>../Parent/pom.xml</relativePath>

</parent>

此時如果子工程的 groupId 和 version 如果和父工程重複則可以刪除。

11.4 在父工程中管理依賴

將 Parent 專案中的 dependencies 標籤，用 dependencyManagement 標籤括起來

<dependencyManagement>

  <dependencies>

    <dependency>

      <groupId>junit</groupId>

      <artifactId>junit</artifactId>

      <version>4.9</version>

      <scope>test</scope>

    </dependency>

  </dependencies>

</dependencyManagement>

在子專案中重新指定需要的依賴，刪除範圍和版本號

<dependencies>

  <dependency>

    <groupId>junit</groupId>

    <artifactId>junit</artifactId>

  </dependency>

</dependencies>

12 聚合

12.1 為什麼要使用聚合？

將多個工程拆分為模組後，需要手動逐個安裝到倉庫後依賴才能夠生效。修改原始碼後也需要逐個手動進行 clean 操作。而使用了聚合之後就可以批量進行 Maven 工程的安裝、清理工作。

12.2 如何配置聚合？

在總的聚合工程中使用 modules/module 標籤組合，指定模組工程的相對路徑即可

<modules>

  <module>../Hello</module>

  <module>../HelloFriend</module>

  <module>../MakeFriends</module>

</modules>

13 Maven 酷站

我們可以到 http://mvnrepository.com/ 搜尋需要的 jar 包的依賴資訊。