Maven：自動化構建工具

Maven的出現是爲了解決如下的問題：

---

• 一個項目就是一個工程，若是一個項目很龐大，用package來組織的項目很差管理。最好一個項目一個工程，利於分工管理。利用maven能夠將一個項目拆分紅多個工程。

• 項目中的jar包須要手動複製粘貼到WEB-INF/lib目錄下

  帶來的問題是：一樣的jar包重複出如今不一樣的項目工程中，一方面浪費存儲資源，另外一方面，也讓工程比較臃腫。藉助maven，能夠將jar包僅僅保存在倉庫中，有須要使用的工程引用這個文件接口，並不須要真的把jar包複製過來。

• jar包須要別人爲咱們準備好，或者本身到官網下載

  • 不一樣技術的官網提供jar包下載的形式五花八門。

  • 還有一些技術的官網就是經過maven或者svn等專門的工具來提供下載的。

  • 經過不規範的方式下載的jar包，那麼其中的內容也多是不規範的。

  • 藉助於Maven能夠以一種規範的方式下載jar包，由於全部知名框架或者第三方工具的jar包已經按照統一的規範存放在了Maven的中央倉庫中

  • 以規範的方式下載的jar包，內容也是規範的

    Tips：統一規範對整我的類社會的發展是很重要的

• 一個jar包依賴的其餘jar包須要本身手動加入到項目中

  • 若是全部jar包之間的依賴關係都須要程序員本身很是的清楚瞭解，那麼就會極大的增長學習成本。

  • Maven會自動將被依賴的jar包導入進來。

Maven是什麼

---

• Maven是一款服務於java平臺的自動化構建工具。Make--》Ant--》Maven--》Gradle

• 構建

  【1】概念：以「java源文件」、「框架配置文件」、「JSP」、「HTML」、「圖片」等資源爲「原材料」，去「生產」一個能夠運行的項目的過程。

  【2】編譯：Java源文件（.java）--》編譯--》class字節碼文件（.calss）--》交給JVM去執行

  【3】部署：一個BS項目最終運行的並非動態web工程自己，而是這個動態web工程變異的結果。

  ​ 生的雞---》處理---》熟的雞

  ​ 動態web工程--》編譯、部署--》編譯結果

  【4】運行時環境：實際上是一組jar包的引用，並無把jar包自己複製到工程中，因此並非目錄。

注意：開發過程當中，全部的路徑或配置文件中配置的類路徑都是以編譯結果的目錄結構爲標準的。

day：20200303

一、構建過程當中的各個環節

【1】清理：將之前編譯獲得的舊的class文件刪除，爲下一次編譯作準備

【2】編譯：將java源程序編碼成class字節碼文件

【3】測試：自動測試，自動調用JUnit程序

【4】報告：測試程序執行的成果

【5】打包：動態web工程打war包，java工程打jar包

【6】安裝：Maven的特定的概念----將打包獲得的文件複製到「倉庫」中指定的位置。

【7】部署：將動態web工程生成的war包複製到servlet容器的指定路徑下，使其能夠運行

二、安裝Maven核心程序

【1】檢查java 環境：echo %JAVA_HOME%

【2】解壓Maven程序的核心程序的壓縮包，放在一個非中文無空格路徑下

【3】配置Maven環境變量MAVEN_HOME或M2_HOME，還有path

注意：配置M2_HOME能夠避免MAVEN老版本可能出現的問題

三、Maven的核心概念

【1】約定的目錄結構

【2】POM

【3】座標

【4】依賴

【5】倉庫

【6】生命週期、插件、目標

【7】繼承

【8】聚合

四、第一個Maven工程

• 建立約定的目錄結構

【1】根目錄：工程名

【2】src目錄：源碼

【3】POM.xml：Maven工程的核心配置文件

【4】main目錄：存放主程序

【5】test目錄：存放測試程序

【6】java目錄：存放java的源文件

【7】resource目錄：存放框架或其餘工具的配置文件

• 爲何要遵照規定的目錄結構

  • maven要負責項目的自動化構建，以編譯爲例，Maven想要自動進行編譯，那麼它必須知道java源文件保存在哪裏

  • 若是咱們本身自定義的東西想讓框架或者工具知道，那麼就要符合框架或者工具的規則，有如下兩種方式：

    • 以配置的方式明確告訴框架
    • 遵照框架內部已經存在的約定

  • 約定 > 配置 > 代碼

• 配置文件示例

• Maven經常使用命令

  【1】mvn clean：清理

  【2】mvn compile： 編譯主程序

  【3】mvn test-compile：編譯測試程序

  【4】mvn test：執行測試

  【5】mvn package：打包

  【6】mvn install：安裝

  【7】mvn site：生成站點

• 關於聯網的問題

  • Maven的核心程序中僅僅定義了抽象的生命週期，可是具體的工做必須由特定的插件來完成。而插件自己並不包含在Maven的核心程序中
  • 當咱們執行的maven命令須要用到某些插件時，Maven核心程序會首先到本地倉庫中查找
  • 本地倉庫的默認位置：【系統中當前用戶的家目錄】.m2\repository
  • Maven核心程序若是在本地倉庫中找不到須要的插件，那麼它會自動鏈接外網，到中央倉庫下載。
  • 若是此時沒法鏈接外網，那麼就會構建失敗
  • 修改默認本地倉庫的位置可讓Maven核心程序到咱們事先準備好的目錄下去查找插件

• POM（Project Object Model ）項目對象模型

  擴展：DOM（Document Object Model）

  • pom.xml對於Maven工程是核心配置文件，與構建過程相關的一切設置都在設個文件中進行配置。

• Maven座標：使用三個向量在倉庫中惟必定位一個Maven工程

  【1】groupid：公司或組織域名倒序+項目名

  【2】artifactid：模塊名稱

  【3】version：版本

• Maven工程的座標與倉庫中路徑的對應關係

注意：版本號以後再將模塊名和版本名拼接就是文件名稱

• Maven倉庫

  • 分類：

    【1】當前電腦上部署的倉庫目錄，爲當前電腦上全部的Maven服務

    【2】遠程倉庫：私服、中央倉庫、中央倉庫的鏡像

  • 倉庫中保存的內容：Maven工程

    【1】Maven自身所須要的插件

    【2】第三方框架或工具的jar包

    【3】咱們本身開發的Maven工程

• 依賴

  【1】Maven解析依賴時會到本地倉庫中查找被依賴的jar包

  ​ 對於咱們本身開發的Maven工程，執行install命令，項目就會打包進入Maven倉庫

  【2】依賴的範圍

  • compile範圍依賴

    • 對主程序是否有效：有效
    • 對測試程序是否有效：有效
    • 是否參與打包：參與
    • 是否參與部署：參與
    • 典型例子：spring-core

  • test範圍依賴

    • 對主程序是否有效：無效
    • 對測試程序是否有效：有效
    • 是否參與打包：不參與

  • provided

    • 對主程序是否有效：有效
    • 對測試程序是否有效：有效
    • 是否參與打包：不參與
    • 是否參與部署：不參與
    • 典型例子：servlet-api.jar

• 生命週期：

  • 各個構建環節的執行順序：不能打亂順序，必須按照既定的正確順序來執行
  • Maven的核心程序中定義了抽象的生命週期，生命週期中各階段的具體任務是由插件來完成的
  • Maven核心程序爲了更好的實現自動化構建，按照這一特色執行生命週期中的各個階段：不論如今要執行生命週期的哪個階段， 都是從這個生命週期最初的階段開始執行

• 插件和目標

  【1】生命週期的各個階段僅僅定義了要執行的任務是什麼

  【2】各個階段和插件的目標是對應的

  【3】類似的目標由特定的插件來完成

  【4】你能夠將目標看作：調用插件功能的命令

day：20200304

• 在集成開發環境IDE中使用Maven

  Maven插件的設置

  【1】installations：指定Maven核心程序的位置。不建議使用插件自帶的Maven程序

  【2】User Settings：指定settings的路徑，進而獲取本地倉庫的位置

• Maven基本操做

  【1】建立Maven版的Java工程

  【2】建立Maven版本的額web工程

  【3】執行Maven命令

• 指定項目使用的java版本

• 依賴（高階）

  • 依賴的傳遞性

好處：能夠傳遞的依賴沒必要在每一個模塊工程中都重複聲明，在「最下面」的工程中依賴一次便可

【注意】：非compile範圍的依賴不能傳遞。因此在各個工程模塊中，若是有須要就得重複聲明依賴
複製代碼

• 依賴的排除

  【1】須要設置依賴排除的場合：

【2】用法，在相關的依賴中添加Exclusions
複製代碼

• 依賴的原則

  【1】做用：解決模塊工程之間的jar包衝突問題

  【2】情景設定1：驗證路徑最短者優先的原則

  

  【3】情景設定2：驗證路徑相同時先聲明者優先

• 統一管理依賴的版本

  【1】情景舉例：

​ 這裏對Spring各個jar包的依賴版本都是4.0.0，若是要統一升級版本爲4.1.1，該怎麼操做?

​ 手動修改，會致使遺漏問題

【2】建議配置方式

​ i.使用properties標籤內使用自定義標籤統一聲明版本號

​ ii.在須要統一版本的位置，使用如下的方式

• 繼承

  【1】現狀：test域中的依賴是不能傳遞的，必然會分散在各個模塊中，容易形成版本不一致的問題，那麼咱們該如何對依賴進行版本管理呢？

  • Hello依賴的JUnit版本：4.0
  • HelloFriend依賴的JUnit版本：4.0
  • MakeFriends依賴的JUnit版本：4.9

  【2】需求：統一管理各個模塊功能中對JUnit依賴的版本

  【3】解決思路：將Junit依賴版本統一提取到「父」工程中，在子工程中聲明依賴時不指定版本，以父工程中統一設定的爲準。同時也便於修改

  【4】操做步驟：

  ​ a。建立一個Maven工程做爲父工程。注意：打包的方式爲POM

​ b。在子工程中聲明對父工程的引用

​ c。將子工程的座標中與父工程座標中重複的內容刪掉

​ d。在父工程中統一JUnit依賴的版本

​ e。在子工程中刪除JUnit依賴的

注意：配置繼承後，執行安裝命令時要先安裝父工程

• 聚合：

  • 做用：一鍵安裝各類模塊工程

  • 配置方式：在一個「總的聚合工程」中，配置各個參與聚合的模塊

• 使用方式：在聚合工程的pom.xml上右鍵--》run as --》maven install

• Maven的自動部署

2020-03-04 學習完畢 bilibili