【Maven】總結

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

1 Why?

1.1 真的需要嗎？

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

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

1.2 究竟為什麼？

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

  1. ①添加第三方 jar 包
    在今天的 JavaEE 開發領域，有大量的第三方框架和工具可以供我們使用。要使用這些 jar 包最簡單的方法就是複製粘貼到 WEB-INF/lib 目錄下。但是這會導致每次創建一個新的工程就需要將 jar 包重複複製到 lib 錄下，從而造成工作區中存在大量重複的文件，讓我們的工程顯得很臃腫。
    而使用 Maven 後每個 jar 包本身只在本地倉庫中保存一份，需要 jar 包的工程只需要以坐標的方式簡單的引用一下就可以了。不僅極大的節約了存儲空間，讓項目更輕巧，更避免了重複文件太多而造成的混亂。

  2. ②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 包的部分依賴關係

  3. ③獲取第三方 jar 包
    JavaEE 開發中需要使用到的 jar 包種類繁多，幾乎每個 jar 包在其本身的官網上的獲取方式都不盡相同。為了查找一個 jar 包找遍互聯網，身心俱疲，沒有經歷過的人或許體會不到這種折磨。不僅如此，費勁心血找的 jar 包里有的時候並沒有你需要的那個類，又或者又同名的類沒有你要的方法——以不規範的方式獲取的 jar 包也往往是不規範的。
    使用 Maven 我們可以享受到一個完全統一規範的 jar 包管理體系。你只需要在你的項目中以坐標的方式依賴一個 jar 包，Maven 就會自動從中央倉庫進行下載，並同時下載這個 jar 包所依賴的其他 jar 包——規範、完整、準確！一次性解決所有問題！

    Tips：在這裡我們順便說一下，統一的規範幾乎可以說成是程式設計師的最高信仰。如果沒有統一的規範，就意味著每個具體的技術都各自為政，需要以諸多不同的特殊的方式加入到項目中；好不容易加入進來還會和其他技術格格不入，最終受苦的是我們。而任何一個領域的統一規範都能夠極大的降低程式設計師的工作難度，減少工作量。
    例如：USB 介面可以外接各種設備，如果每個設備都有自己獨特的介面，那麼不僅製造商需要維護各個介面的設計方案，使用者也需要詳細了解每個設備對應的介面，無疑是非常繁瑣的。

  4. ④將項目拆分成多個工程模組
    隨著 JavaEE 項目的規模越來越龐大，開發團隊的規模也與日俱增。一個項目上千人的團隊持續開發很多年對於 JavaEE 項目來說再正常不過。那麼我們想像一下：幾百上千的人開發的項目是同一個 Web 工程。那麼架構師、項目經理該如何劃分項目的模組、如何分工呢？這麼大的項目已經不可能通過 package 結構來劃分模組，必須將項目拆分成多個工程協同開發。多個模組工程中有的是 Java 工程，有的是 Web 工程。
    那麼工程拆分後又如何進行互相調用和訪問呢？這就需要用到 Maven 的依賴管理機制。大家請看我們的 Survey 調查項目拆分的情況：

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

2 What?

2.1 Maven 簡介

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

2.2 什麼是構建

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

  1. ①純 Java 程式碼
    大家都知道，我們 Java 是一門編譯型語言，.java 擴展名的源文件需要編譯成.class 擴展名的位元組碼文件才能夠執行。所以編寫任何 Java 程式碼想要執行的話就必須經過編譯得到對應的.class 文件。

  2. ②Web 工程
    當我們需要通過瀏覽器訪問 Java 程式時就必須將包含 Java 程式的 Web 工程編譯的結果「拿」到伺服器上的指定目錄下，並啟動伺服器才行。這個「拿」的過程我們叫部署。
    我們可以將未編譯的 Web 工程比喻為一隻生的雞，編譯好的 Web 工程是一隻煮熟的雞，編譯部署的過程就是將雞燉熟。
    Web 工程和其編譯結果的目錄結構對比見下圖：

  3. ③實際項目
    在實際項目中整合第三方框架，Web 工程中除了 Java 程式和 JSP 頁面、圖片等靜態資源之外，還包括第三方框架的 jar 包以及各種各樣的配置文件。所有這些資源都必須按照正確的目錄結構部署到伺服器上，項目才可以運行。
    所以綜上所述：構建就是以我們編寫的 Java 程式碼、框架配置文件、國際化等其他資源文件、JSP 頁面和圖片等靜態資源作為「原材料」，去「生產」出一個可以運行的項目的過程。
    那麼項目構建的全過程中都包含哪些環節呢？

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

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

2.4 自動化構建

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

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

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

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

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

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

2.5 Maven 核心概念

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

  1. ①POM
  2. ②約定的目錄結構
  3. ③坐標
  4. ④依賴管理
  5. ⑤倉庫管理
  6. ⑥生命周期
  7. ⑦插件和目標
  8. ⑧繼承
  9. ⑨聚合

3 How?

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

4 約定的目錄結構

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

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

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

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

5 POM

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

6 坐標

6.1 幾何中的坐標

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

6.2 Maven 的坐標

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

  1. [1]groupid：公司或組織的域名倒序+當前項目名稱
  2. [2]artifactId：當前項目的模組名稱
  3. [3]version：當前模組的版本
<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>

6.3 如何通過坐標到倉庫中查找 jar 包？

  1. [1]將 gav 三個向量連起來
    com.atguigu.maven+Hello+0.0.1-SNAPSHOT

  2. [2]以連起來的字元串作為目錄結構到倉庫中查找
    com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

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

7 依賴

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

  1. ①依賴的目的是什麼
    當 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>
  2. ②依賴的範圍
    大家注意到上面的依賴資訊中除了目標 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
      主程式 √ × √
      測試程式 √ √ √
      參與部署 √ × ×

  3. ③依賴的傳遞性
    A 依賴 B，B 依賴 C，A 能否使用 C 呢？那要看 B 依賴 C 的範圍是不是 compile，如果是則可用，否則不
    可用。

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

    1. [1]情景舉例

    2. [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. [3]排除後的效果

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

    1. [1]統一聲明版本號

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

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

    2. [2]引用前面聲明的版本號

      <dependencies>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>${atguigu.spring.version}</version>
  </dependency>
  ……
</dependencies>

    3. [3]其他用法

      <properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
  6. ⑥依賴的原則：解決 jar 包衝突

    1. [1]路徑最短者優先

    2. [2]路徑相同時先聲明者優先

      這裡「聲明」的先後順序指的是 dependency 標籤配置的先後順序。

8 倉庫

8.1 分類

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

8.2 倉庫中的文件

  1. [1]Maven 的插件
  2. [2]我們自己開發的項目的模組

  3. [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 生命周期一共包含了三個階段：

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

9.3 Site 生命周期

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

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

9.4 Default 生命周期

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

  1. validate
  2. generate-sources
  3. process-sources
  4. generate-resources
  5. process-resources 複製並處理資源文件，至目標目錄，準備打包。
  6. compile 編譯項目的源程式碼。
  7. process-classes
  8. generate-test-sources
  9. process-test-sources
  10. generate-test-resources
  11. process-test-resources 複製並處理資源文件，至目標測試目錄。
  12. test-compile 編譯測試源程式碼。
  13. process-test-classes
  14. test 使用合適的單元測試框架運行測試。這些測試程式碼不會被打包或部署。
  15. prepare-package
  16. package 接受編譯好的程式碼，打包成可發布的格式，如 JAR。
  17. pre-integration-test
  18. integration-test
  19. post-integration-test
  20. verify
  21. install 將包安裝至本地倉庫，以讓其它項目依賴。
  22. 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 酷站

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

Tags:

VirMach 便宜 VPS

QNews

QNews