Maven：自動化構建工具

zeroOne發表於2020-03-04

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、構建過程中的各個環節

【1】清理：將以前編譯得到的舊的class檔案刪除，為下一次編譯做準備

【2】編譯：將java源程式編碼成class位元組碼檔案

【3】測試：自動測試，自動呼叫JUnit程式

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

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

【6】安裝：Maven的特定的概念----將打包得到的檔案複製到“倉庫”中指定的位置。

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

2、安裝Maven核心程式

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

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

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

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

3、Maven的核心概念

【1】約定的目錄結構

【2】POM

【3】座標

【4】依賴

【5】倉庫

【6】生命週期、外掛、目標

【7】繼承

【8】聚合

4、第一個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