神一樣的工具 —— Maven

🤹 Maven#

🧫 背景#

我們整個軟體生命周期基本劃分為：需求（業務提需求、產品寫文檔、技術定排期），開發（需求分析，資料庫設計，編碼，也包括單元測試等自測），測試，打包對外發布，版本更新（根據時間與業務需求變化又開始重複之前的開發測試等過程）。
專案自動化構建
Maven (pom.xml)。基於 Java 開發，但是功能更全面更強大，通過修改相關配置文件（pom.xml），自動化支持軟體生命周期的幾乎所有過程（編譯、測試、打包發布、安裝），還有一個比較強大的功能：JAR 包依賴功能。

👨‍💻 命令#

mvn clean
清理刪除以前的編譯結果，為重新編譯做好準備
mvn compile
編譯將 Java 源程序編譯為字節碼文件
mvn test
測試針對專案中的關鍵點進行測試，確保專案在迭代開發過程中關鍵點的正確性
報告（）：在每一次測試後以標準的格式記錄和展示測試結果
mvn package
將一個包含諸多文件的工程封裝為一個壓縮文件用於安裝或部署。Java 工程對應 jar 包，Web 工程對應 war 包。
mvn install
安裝在 Maven 環境下特指將打包的結果 —— jar 包或 war 包安裝到本地倉庫中。
mvn deploy
部署將打包的結果部署到遠程倉庫或將 war 包部署到伺服器上運行

mvn -version/-v
顯示版本信息

建議在每個操作前先進行 mvn clean 刪除，只執行 mvn clean 會刪除 target 目錄 （存疑？）。
Maven 命令執行時有個特點，它會把之前的過程先執行完畢。比如：
在執行 mvn clean package 時，但它實際上是先執行了 mvn clean compile，再執行 test，再執行 package。

🥑 核心概念#

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

POM
約定的目錄結構
坐標
依賴管理
倉庫管理
生命周期
插件和目標
繼承
聚合

Maven 的核心程序中僅僅定義了抽象的生命周期，而具體的操作則是由 Maven 的插件來完成的。可是 Maven 的插件並不包含在 Maven 的核心程序中，在首次使用時需要聯網下載。下載得到的插件會被保存到本地倉庫中。本地倉庫默認的位置是：~/.m2/repository。

🤖 POM#

**Project Object Model：專案對象模型。** 將 Java 工程的相關信息封裝為對象作為便於操作和管理的模型。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>demo</artifactId>
    <version>1.0-SNAPSHOT</version>
    <name>demo</name>
    <packaging>war</packaging>

    <properties>
    </properties>

    <dependencies>    
    </dependencies>

    <build>
        <plugins>
        </plugins>
    </build>
</project>

⚓ 坐標#

Maven 工程的核心配置。

G-A-V：使用三個向量子倉庫中唯一定位一個 Maven 工程

groupid：公司或組織域名倒序
artifactid：模組名，也是實際專案的名稱
version：當前專案的版本

  <groupId>ink.onei</groupId>
  <artifactId>Hello</artifactId>
  <version>0.0.1-SNAPSHOT</version>

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

將 gav 三個向量連起來
ink.onei+Hello+0.0.1-SNAPSHOT
以連起來的字符串作為目錄結構到倉庫中查找
ink/onei/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

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

🏗️ 結構#

Java 開發領域普遍認同的一個觀點：約定 > 配置 > 編碼（能用配置解決的問題就不編碼，能基於約定的就不配置）

Maven 專案目錄

專案根目錄         工程名作為根目錄
├─src              源碼目錄
│  ├─main          主程序目錄
│  │  ├─java       主程序的Java源文件目錄
│  │  │
│  │  └─resources  主程序的資源文件目錄
│  │
│  └─test          測試程序目錄
│      ├─java      測試程序目錄
│      │
│      └─resources 測試程序的資源文件目錄
└─target           編譯結構                              
    ├─classes
    │
    └─generated-sources
        └─annotations

🎨 依賴#

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

依賴的目的是什么#

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

<dependency>
  <groupId>ink.onei</groupId>
  <artifactId>Hello</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <scope>compile</scope>            
</dependency>

依賴的範圍#

有時依賴信息中除了目標包的坐標還有一個 scope 設置，這就是依賴的範圍。依賴的範圍有幾個可選值，常用的有：compile、test、provided 三個，當然還有不常用的 runtime、system...

compile：默認範圍，編譯測試運行都有效
provided：在編譯和測試時有效
runtime：在測試和運行時有效
test：只在測試時有效
system：在編譯和測試時有效，與本機系統關聯，可移植性差

常用依賴範圍有效性總結

	compile	test	provided
主程序	✔️	❌	✔️
測試程序	✔️	✔️	✔️
參與部署	✔️	❌	❌

依賴的傳遞性#

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

依賴的排除#

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

<dependency>
    <groupId>ink.onei</groupId>
    <artifactId>Hello</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <scope>compile</scope>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
            </exclusion>
    </exclusions>
</dependency>

統一管理所依賴版本#

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

統一聲明版本號

<properties>
    <starfish.spring.version>4.1.1.RELEASE</starfish.spring.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

引用前面聲明的版本號

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <version>${starfish.spring.version}</version>
  <scope>compile</scope>
</dependency>

依賴的原則#

解決包衝突

路徑最短者優先
路徑相同時先聲明者優先

📦 倉庫管理#

本地倉庫
為當前本機電腦上的所有 Maven 工程服務
遠程倉庫
- 中央倉庫這是默認的倉庫
  架設在 Internet 上，為全世界所有 Maven 工程服務
- 鏡像倉庫通過 sttings.xml 中的 settings.mirrors.mirror 配置
  架設在各個大洲，為中央倉庫分擔流量。減輕中央倉庫的壓力，同時更快的響應用戶請求例如阿里雲鏡像倉庫
- 私服
  架設在當前局域網環境下，為當前局域網範圍內的所有 Maven 工程服務

倉庫中的文件

Maven 的插件
我們自己開發的專案的模組
第三方框架或工具的包

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

其他倉庫#

全局 profile 倉庫，通過 settings.xml 中的 settings.repositories.repository 配置
專案倉庫，通過 pom.xml 中的 project.repositories.repository 配置
專案 profile 倉庫，通過 pom.xml 中的 project.profiles.profile.repositories.repository 配置

repository

🌱 生命周期#

什麼是 Maven 的生命周期#

Maven 生命周期定義了各個構建環節的執行順序，有了這個清單，Maven 就可以自動化的執行構建命令了。

Maven 有三套相互獨立的生命周期，分別是：

Clean Lifecycle 在進行真正的構建之前進行一些清理工作
Default Lifecycle 構建的核心部分，編譯，測試，打包，安裝，部署等等
Site Lifecycle 生成專案報告，站點，發布站點

它們是相互獨立的，你可以僅僅調用 clean 來清理工作目錄，僅僅調用 site 來生成站點。當然你也可以直接運行 mvn clean install site 運行所有這三套生命周期。每套生命周期都由一組階段 (Phase) 組成，我們平時在命令行輸入的命令總會對應於一個特定的階段。比如，運行 mvn clean，這個 clean 是 Clean 生命周期的一個階段。有 Clean 生命周期，也有 clean 階段。

Clean 生命周期#

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

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

Site 生命周期#

pre-site 執行一些需要在生成站點文檔之前完成的工作
site 生成專案的站點文檔
post-site 執行一些需要在生成站點文檔之後完成的工作，並且為部署做準備
site-deploy 將生成的站點文檔部署到特定的伺服器上這裡經常用到的是 site 階段和 site-deploy 階段，用以生成和發布 Maven 站點，這可是 Maven 相當強大的功能，Manager 比較喜歡，文檔及統計數據自動生成，很好看。

Default 生命周期#

Default 生命周期是 Maven 生命周期中最重要的一個，絕大部分工作都發生在這個生命周期中（列出一些重要階段）

validate 驗證工程是否正確，所有需要的資源是否可用。
compile 編譯專案的源代碼。
test 使用合適的單元測試框架來測試已編譯的源代碼。這些測試不需要已打包和布署。
package 把已編譯的代碼打包成可發布的格式，比如 jar、war 等。
integration-test 如有需要，將包處理和發布到一個能夠進行集成測試的環境。
verify 運行所有檢查，驗證包是否有效且達到質量標準。
install 把包安裝到 maven 本地倉庫，可以被其他工程作為依賴來使用。
deploy 在集成或者發布環境下執行，將最終版本的包拷貝到遠程的 repository，使得其他的開發者或者工程可以共享

生命周期與自動化構建#

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

🔌 插件和目標#

Maven 的核心僅僅定義了抽象的生命周期，具體的任務都是交由插件完成的
每個插件都能實現多個功能，每個功能就是一個插件目標
Maven 的生命周期與插件目標相互綁定，以完成某個具體的構建任務
例如：compile 就是插件 maven-compiler-plugin 的一個目標；pre-clean 是插件 maven-clean-plugin 的一個目標

🧬 繼承#

為什麼需要繼承機制？

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

創建父工程 創建父工程和創建一般的 Java 工程操作一致，唯一需要注意的是：打包方式處要設置為 pom
在子工程中引用父工程，從當前目錄到父專案的 pom.xml 文件的相對路徑

 <parent>
     <groupId>com.starfish.maven</groupId>
    <artifactId>Parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <!-- 以當前文件為基準的父工程pom.xml文件的相對路徑 -->
    <relativePath>../Parent/pom.xml</relativePath>
</parent>

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

在父工程中管理依賴將 Parent 專案中的 dependencies 標籤，用 dependencyManagement 標籤括起來

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.9</version>
        <scope>test</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

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

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
</dependency>

💞 聚合#

為什麼要使用聚合？

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

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

<!-- 配置聚合 -->
<modules>
    <!-- 指定各個子工程的相對路徑 -->
    <module>starfish-learn-grpc</module>
    <module>starfish-learn-kafka</module>
    <module>starfish-web-demo</module>
</modules>