maven實戰(zhàn)總結(jié)，工作中常見操作

點擊上方?好好學(xué)java?，選擇?星標(biāo)?公眾號

思維導(dǎo)圖

Maven 與構(gòu)建

什么是 Maven

翻譯：知識的積累、專家、內(nèi)行?？缙脚_的項目管理工具。Apache 組織的開源項目。主要服務(wù)于基于 Java 平臺的項目構(gòu)建、依賴管理和項目信息管理。

類似于 linux 平臺的 yum、apt，前端領(lǐng)域的 npm。Maven 前身為 Ant 目前 tomcat 的源碼就是用 Ant 來構(gòu)建和管理，更先進(jìn)的工具有 Gradle， Spring 工程在用。

什么是構(gòu)建

何為構(gòu)建：編譯、運行單元測試、生成文檔、打包、部署的過程，這就是構(gòu)建。

構(gòu)建的步驟：

• 清理 clean：將以前編譯得到的舊文件 class 字節(jié)碼文件刪除。

• 編譯 compile：將 java 源程序編譯成 class 字節(jié)碼文件。

• 測試 test：自動測試，自動調(diào)用 junit 程序。

• 報告 report：測試程序執(zhí)行的結(jié)果。

• 打包 package：動態(tài) Web 工程打 War 包，java 工程打 jar 包。

• 安裝 install：將打包得到的文件復(fù)制到 “倉庫” 中的指定位置（Maven特定的概念）。

• 部署 deploy：將動態(tài) Web 工程生成的 war 包復(fù)制到 Servlet 容器下，使其可以運行。

項目骨架

pom：Project Object Model

根目錄：工程名
|---src：源碼
|---|---main:主程序
|---|---|---java：主程序代碼路徑
|---|---|---resource：主程序配置文件路徑
|---|---test：測試
|---|---|---java：測試代碼路徑
|---|---|---resource：測試配置文件路徑
|---pom.xml：maven 配置文件

簡單演示

##?1.?使用?archetype?命令生成?maven?簡單骨架
mvn?archetype:generate?-DarchetypeCatalog=internal

##?2.?編譯當(dāng)前生成的項目
mvn?compile

##?3.?使用其他命令
mvn?test-compile??
mvn?package??
mvn?clean?
mvn?install
mvn?depoly?暫時不演示

坐標(biāo)與依賴

什么是坐標(biāo)

類比為數(shù)學(xué)中平面幾何，坐標(biāo)（x、y ），任何一個坐標(biāo)都能唯一標(biāo)識該平面中的一個點。

該點對應(yīng)到 maven 就是 .jar、.war 等文件的文件。

Maven 使用 groupId、artifactId、version、packaging、classifier 等元素來組成自己的坐標(biāo)，并定義一組這樣的規(guī)則，只要能提供正確坐標(biāo)元素 Maven 就能找到對應(yīng)的構(gòu)件。

坐標(biāo)元素

• groupId：定義當(dāng)前 Maven 項目隸屬的實際項目。

• artifactId：定義實際項目中的一個 Maven 項目（模塊）。

• packaging：定義 Maven 項目打包方式。jar、war、pom。默認(rèn)為 jar。

• version：定義 Maven 項目當(dāng)前所處的版本。

• classifier：區(qū)分從同一 artifact 構(gòu)建的具有不同內(nèi)容的構(gòu)件。

classifier 使用場景

區(qū)分基于不同 JDK 版本的包

<dependency>??
????<groupId>net.sf.json-libgroupId>???
????<artifactId>json-libartifactId>???
????<version>2.2.2version>??
????<classifier>jdk13classifier>????
????
dependency>?

區(qū)分項目的不同組成部分

<dependency>??
????<groupId>net.sf.json-libgroupId>???
????<artifactId>json-libartifactId>???
????<version>2.2.2version>??
????<classifier>jdk15-javadocclassifier>????
????
dependency>

構(gòu)件名與坐標(biāo)是對應(yīng)的，一般規(guī)則是：artifactId-version[-classifier].packaging。

依賴聲明

<dependencies>
??<dependency>
????<groupId>groupId>
????<artifactId>artifactId>
????<version>version>
????<type>type>
????<optional>optional>
????<exclusions>
??????<exclusion>
????????<artifactId>artifactId>
????????<groupId>groupId>
??????exclusion>
??????...
????exclusions>
??dependency>
??...
dependencies>

• groupId、artifactId、version：依賴的基本坐標(biāo)。

• type：依賴的類型，對應(yīng)項目對應(yīng)的 packaging，一般不必聲明。

• scope：依賴的范圍，后面詳解。

• optional：標(biāo)記依賴是否可選。

• exclusions：用來排除傳遞性依賴。

依賴范圍

• compile：編譯依賴范圍

  如果沒有指定，默認(rèn)使用該依賴范圍。對于編譯、測試、運行三種 classpath 都有效。如：spring-core。

• test：測試依賴范圍

  只對于測試 classpath 有效，只需要在編譯測試及運行測試才需要，在打包的時候不會打進(jìn)去。如：JUnit。

• provided：已提供依賴范圍

  對于編譯和測試 classpath 有效，但運行時無效。如：servlet-api 編譯和測試項目的時候都需要，但在實際運行中，容器已經(jīng)提供，不需要 maven 重復(fù)的引用。

• runtime：運行時依賴范圍

  對于測試和運行的 classpath 有效，但在編譯主代碼時無效。如：JDBC 驅(qū)動的實現(xiàn)包。只有在執(zhí)行測試或者運行項目時，才需要具體的 JDBC 驅(qū)動。

• system：系統(tǒng)依賴范圍

  與 provided 依賴范圍完全一致，但是使用該范圍時必須通過 systemPath 元素顯式地指定依賴文件的路徑。由于此類依賴不是通過 maven 倉庫解析的，而且往往與本機(jī)系統(tǒng)綁定，可能造成構(gòu)建不可移植，因此應(yīng)該謹(jǐn)慎使用。systemPath 元素可以引用環(huán)境變量，如：

  <dependencies>
  ??<dependency>
  ????<groupId>javax.sqlgroupId>
  ????<artifactId>jdbc-stdxtartifactId>
  ????<version>2.0version>
  ????<scope>systemscope>
  ????<systemPath>${java.home}/lib/rt.jarsystemPath>
  ??dependency>
  dependencies>
  

• import：導(dǎo)入依賴范圍

  只在 dependencyManagement 標(biāo)簽中生效，導(dǎo)入已經(jīng)定義好的 pom 文件中 dependencyManagement 節(jié)點內(nèi)容

  <dependencyManagement>
  ??<dependencies>
  ????<dependency>
  ??????<groupId>org.springframeworkgroupId>
  ??????<artifactId>spring-framework-bomartifactId>
  ??????<version>4.3.16.RELEASEversion>
  ??????<type>pomtype>
  ??????<scope>importscope>
  ????dependency>
  ??dependencies>
  dependencyManagement>
  

依賴機(jī)制與特性

依賴傳遞

• A->B(compile)：第一直接依賴

• B->C(compile)：第二直接依賴

• A->C(compile)：傳遞性依賴

當(dāng)在A中配置

<dependency>??
????<groupId>com.BgroupId>??
????<artifactId>BartifactId>??
????<version>1.0version>??
dependency>

則會自動導(dǎo)入 C 包。

傳遞性依賴的范圍如下圖所示：

依賴調(diào)解

當(dāng)傳遞性依賴出現(xiàn)問題時，能夠清楚地知道該傳遞性依賴是從哪條依賴路徑中引入的。

一、路徑最近者優(yōu)先原則

• A->B->C->X(1.0)
• A->D->X(2.0)

由于只能導(dǎo)入一個版本的包，按照最短路徑選擇導(dǎo)入 X(2.0)

二、第一聲明者優(yōu)先原則

• A->B->Y(1.0)
• A->C->Y(2.0)

此時由于依賴路徑長度一致，按照第一聲明者優(yōu)先原則。在路徑長度一致的前提下，如果 B 依賴在 POM 文件中聲明順序在 C 依賴之前，那么 Y(1.0) 則會被引入。如下依賴可用于測試：

<dependencies>
??<dependency>
????<groupId>org.apache.httpcomponentsgroupId>
????<artifactId>httpclientartifactId>
????<version>4.4.1version>
????<exclusions>
??????<exclusion>
????????<groupId>commons-codecgroupId>
????????<artifactId>commons-codecartifactId>
??????exclusion>
????exclusions>
??dependency>

??<dependency>
????<groupId>org.apache.poigroupId>
????<artifactId>poiartifactId>
????<version>3.9version>
????<exclusions>
??????<exclusion>
????????<groupId>commons-codecgroupId>
????????<artifactId>commons-codecartifactId>
??????exclusion>
????exclusions>
??dependency>

??<dependency>
????<groupId>commons-codecgroupId>
????<artifactId>commons-codecartifactId>
????<version>1.10version>
??dependency>

dependencies>

這里有一點需要特別注意，看如下依賴：

<dependencies>
??<dependency>
????<groupId>commons-codecgroupId>
????<artifactId>commons-codecartifactId>
????<version>1.11version>
??dependency>

??<dependency>
????<groupId>commons-codecgroupId>
????<artifactId>commons-codecartifactId>
????<version>1.10version>
??dependency>
dependencies>

按照兩原則，期望得到的結(jié)果應(yīng)該是 1.11 版本的構(gòu)建將被依賴。但實際結(jié)果卻依賴了 1.10 版本。what！這不是違反了 maven 依賴調(diào)解的最先定義原則？

其實這個是 dependency 插件的功能，默認(rèn)采用的是復(fù)寫的策略，當(dāng)構(gòu)建聲明處于同一 pom 中，且 groupid 和 artifactId 一致時，以最新聲明為準(zhǔn)，后面的覆蓋前面的。

注意這里沒涉及到依賴調(diào)解的功能。我的理解是依賴調(diào)解只發(fā)生于構(gòu)建來自不同 pom 時，而此時構(gòu)建聲明處于同一 pom，故不會觸發(fā)依賴調(diào)解。

可選依賴

A->B、B->X（可選）、B->Y（可選）。

項目 A 依賴于項目 B，項目 B 依賴于項目 X 和 Y。

理論上項目 A 中，會把 B、X、Y 項目都依賴進(jìn)來。

但是 X、Y 兩個依賴對于 B 來講可能是互斥的，如 B 是數(shù)據(jù)庫隔離包，支持多種數(shù)據(jù)庫 MySQL、Oracle，在構(gòu)建 B 項目時，需要這兩種數(shù)據(jù)庫的支持，但在使用這個工具包時，只會依賴一個數(shù)據(jù)庫。

此時就需要在 B 項目 pom 文件中將 X、Y 聲明為可選依賴，如下：

<dependency>??
????<groupId>com.XgroupId>??
????<artifactId>XartifactId>??
????<version>1.0version>??
????<optionnal>trueoptionnal>
dependency>

<dependency>??
????<groupId>com.YgroupId>??
????<artifactId>YartifactId>??
????<version>1.0version>??
????<optionnal>trueoptionnal>
dependency>

使用 optionnal 元素標(biāo)識以后，只會對當(dāng)前項目 B 產(chǎn)生影響，當(dāng)其他的項目依賴 B 項目時，這兩個依賴都不會被傳遞。

項目 A 依賴于項目 B，如果實際應(yīng)用數(shù)據(jù)庫是 X， 則在 A 的 pom 中就需要顯式地聲明 X 依賴。

倉庫

倉庫分類：包括本地倉庫和遠(yuǎn)程倉庫。其中遠(yuǎn)程倉庫包括：私服和中央倉庫。搜索構(gòu)建的順序：

• 本地倉庫

• maven settings profile 中的 repository；

• pom.xml 中 profile 中定義的repository；

• pom.xml 中 repositorys (按定義順序找)；

• maven settings mirror；

• central 中央倉庫；

生命周期

Maven 的生命周期是為了對所有構(gòu)建過程進(jìn)行的抽象和統(tǒng)一，其中包含項目的清理、初始化、編譯、測試、打包、集成測試、驗證、部署和站點生成等幾乎所有的構(gòu)建步驟。

Maven 的生命周期是抽象的，本身是不做任何實際的工作。實際的任務(wù)都交給插件來完成。

意味著 Maven 只在父類中定義了算法的整體結(jié)構(gòu)，子類通過重寫父類的方法，來控制實際行為（設(shè)計模式中的模板方法 Template Method）。偽代碼如下：

public?abstract?class?AbstractBuilder?{
????public?void?build()?{
????????init();
????????compile();
????????test();
????????package();
????????integrationTest();
????????deploy();
????}
????
????protected?abstract?void?init();
????protected?abstract?void?compile();
????protected?abstract?void?test();
????protected?abstract?void?package();
????protected?abstract?void?integrationTest();
????protected?abstract?void?deploy();
}

三套生命周期

Maven 的生命周期并不是一個整體，Maven 擁有三套相互獨立的生命周期，它們分別為 clean、default 和 site。

• clean 生命周期的目的是清理項目；

• default 生命周期的目的是構(gòu)建項目；

• site 生命周期的目的是建立項目站點；

單個生命周期執(zhí)行順序

每個生命周期包含一些階段(phase)，這些階段是有順序的，并且后面的階段依賴于前面的階段。

以 clean 生命周期為例，它包含的階段有 pre-clean、clean和post-clean。當(dāng)調(diào)用 pre-clean 時，只有 pre-clean 階段得以執(zhí)行；

當(dāng)調(diào)用 clean 的時候，pre-clean和clean階段會得以順序執(zhí)行，以此類推。

各個生命周期之間的關(guān)系

三套生命周期本身是相互獨立的，用戶可以僅調(diào)用 clean 生命周期的某個階段，或者僅僅調(diào)用 default 生命周期的某個階段，而不會對其他生命周期產(chǎn)生任何影響。

例如，當(dāng)用戶調(diào)用 clean 生命周期的 clean 階段的時候，不會觸發(fā) default 生命周期的任何階段，反之亦然。

生命周期各個階段詳解

clean

default

包含 23 個階段，此處只介紹重點步驟，如下表：

site

插件

Maven 三套生命周期定義各個階段不做任何實際工作，實際工作都是由插件來完成的，每個生命周期階段都是由插件的目標(biāo)來完成。在 pom 文件中聲明如下（打包源碼文件插件）：

<build>
??<plugins>
????<plugin>
??????<groupId>org.apache.maven.pluginsgroupId>
??????<artifactId>maven-source-pluginartifactId>
??????<version>2.1.1version>
??????<executions>
????????<execution>
??????????<id>attach-sourcesid>
??????????<phase>verifyphase>
??????????<goals>
??????????????<goal>jar-no-forkgoal>
??????????goals>
????????execution>
??????executions>
????plugin>
??plugins>
build>

插件目標(biāo)

一個插件有可能有多個功能、每個功能就是一個目標(biāo)。比如 maven-dependency-plugin 有十多個目標(biāo)，每個目標(biāo)對應(yīng)了一個功能。

插件的目標(biāo)為 dependency:analyze、dependency:tree和dependency:list。

通用寫法：冒號前面是插件前綴，冒號后面是插件的目標(biāo)。比如 compiler:compile。

插件綁定

內(nèi)置綁定

為實現(xiàn)快速構(gòu)建，Maven 有一套內(nèi)置的插件綁定。三套生命周期的插件綁定具體如下（其實是各個生命周期階段與插件的目標(biāo)的綁定）。

其中 default 生命周期的構(gòu)建方式會其打包類型有關(guān)、打包類型在POM中 packaging 指定。一般有 jar、war 兩種類型。下面是默認(rèn)綁定插件與生命周期關(guān)系圖：

自定義綁定

自定義綁定允許我們自己掌控插件目標(biāo)與生命周期的結(jié)合。以生成項目主代碼的源碼 jar 為例。

使用到的插件和它的目標(biāo)為：maven-source-plugin:jar-no-fork。將其綁定到 default 生命周期階段 verify 上（可以任意指定三套生命周期的任意階段）。

<build>
??<plugins>
??????<plugin>
????????<groupId>org.apache.maven.pluginsgroupId>
????????<artifactId>maven-source-pluginartifactId>
????????<version>2.1.1version>
????????<executions>
??????????<execution>
????????????<id>attach-sourcesid>?
????????????
????????????<phase>verifyphase>?
????????????<goals>
???????????????
????????????????<goal>jar-no-forkgoal>
????????????goals>
??????????execution>
????????executions>
??????plugin>
??plugins>
build>

插件配置

• 使用命令行配置

  在 maven 命令中加入 -D 參數(shù)，并伴隨一個參數(shù)鍵=參數(shù)值的形式，來配置插件目標(biāo)參數(shù)。

  如：maven-surefire-plugin 插件提供一個 maven.test.skip 參數(shù)，當(dāng)值為 true 時會跳過執(zhí)行測試：

  ?--?對比?mvn?install
  mvn?install?–Dmaven.test.skip=true
  

• 使用 pom 全局配置

  在聲明插件的時候，對插件進(jìn)行一個全局配置，后面所有使用該插件的都要遵循這個配置。比如指定 maven-compile-plugin 編譯 1.7 版本的源文件：

  <plugin>
  ???<groupId>org.apache.maven.pluginsgroupId>
  ???<artifactId>maven-compiler-pluginartifactId>
  ???<configuration>
  ???????<fork>truefork>
  ???????<source>1.7source>
  ???????<target>1.7target>
  ???configuration>
  plugin>
  

聚合與繼承

聚合：為了一次構(gòu)建多個項目模塊，就需要對多個項目模塊進(jìn)行聚合

<modules>
????<module>模塊一module>
????<module>模塊二module>
????<module>模塊三module>
modules>

繼承：為了消除重復(fù)，把很多相同的配置提取出來，例如：dependency、grouptId，version 等

<parent>??
????<groupId>com.xxxx.mavengroupId>
????<artifactId>parent-projectartifactId>
????<version>0.0.1-SNAPSHOTversion>
????<relativePath>../ParentProject/pom.xmlrelativePath>??
parent>

以下的元素是可以被繼承的：

• groupId，項目組ID；
• version，項目版本；
• description，項目描述信息；
• organazation，項目的組織信息；
• inceptionYear，項目的創(chuàng)始年份；
• developers，項目開發(fā)者信息；
• contributors，項目的貢獻(xiàn)者信息；
• distributionManagement，項目的部署信息；
• issueManagement，項目的缺陷跟蹤系統(tǒng)信息；
• ciManagement，項目的持續(xù)集成系統(tǒng)信息；
• scm，項目的版本控制系統(tǒng)信息；
• mailingLists，項目的郵件列表信息；
• properties，自定義的Maven屬性；
• dependencies，項目的依賴配置；
• dependencyManagement，項目的依賴管理配置；
• repositories，項目的倉庫配置；
• build，包括項目的源碼目錄配置、輸出目錄配置、插件配置、插件管理配置等；
• reporting，包括項目的報告輸出目錄配置、報告插件配置。

注意下面的元素，這些都是不能被繼承的：

• artifactId
• name
• prerequisites

聚合與繼承之間的關(guān)系

• 兩者共同點為，打方式必須都是 pom

• 在實際的項目中，一個 pom 既是聚合 pom 又是父 pom

注：父 pom 中使用 dependencies 引入的依賴也會被子 pom 繼承，所以不要將過多的實際依賴放在父 pom，父 pom 只用于管理，使用 dependencyManagement 標(biāo)簽。

靈活構(gòu)建

使用屬性、 resources 插件資源過濾功能（filter）和 Maven 的 profile 功能，實現(xiàn)環(huán)境的靈活切換

屬性

通過 properties 元素用戶可以自定義一個或者多個 Maven 屬性，然后在 pom 其他的地方使用 ${屬性名} 的方式引用該屬性，這種方式最大意義在于消除重復(fù)。

一、內(nèi)置屬性

• ${basedir} 表示項目根目錄，即包含 pom.xml 文件的目錄

• ${version} 等同于 {pom.version} 表示項目版本

二、POM 屬性

所有 pom 中的元素都可以用 project. 例如 ${project.artifactId} 對應(yīng)了 < project>元素的值。常用的 POM 屬性包括：

• ${project.build.sourceDirectory} : 項目的主源碼目錄，默認(rèn)為 src/main/java/.

• ${project.build.testSourceDirectory} : 項目的測試源碼目錄，默認(rèn)為 /src/test/java/.

• ${project.build.directory} : 項目構(gòu)建輸出目錄，默認(rèn)為 target/.

• ${project.build.outputDirectory} : 項目主代碼編譯輸出目錄，默認(rèn)為 target/classes/.

• ${project.build.testOutputDirectory} : 項目測試代碼編譯輸出目錄，默認(rèn)為 target/testclasses/.

• ${project.groupId}: 項目的 groupId.

• ${project.artifactId} : 項目的 artifactId.

• ${project.version} : 項目的 version, 等同于 ${version}

• ${project.build.finalName} : 項目打包輸出文件的名稱，默認(rèn)為 ${project.artifactId}${project.version}

三、自定義屬性

在 pom 中元素下自定義的 Maven 屬性

<properties>
????<swagger.version>2.2.2swagger.version>
properties>
<dependency>
????<groupId>io.springfoxgroupId>
????<artifactId>springfox-swagger2artifactId>
????<version>${swagger.version}version>
dependency>

四、Settings 屬性

所有用的的 settings.xml 中的設(shè)定都可以通過 settings。前綴進(jìn)行引用與 POM 屬性同理。

如 ${settings.localRepository} 指向用戶本地倉庫的地址

五、Java 系統(tǒng)屬性

所有 Java 系統(tǒng)屬性都可以使用 Maven 屬性引用，例如 ${user.home} 指向了用戶目錄。

可以通過命令行 mvn help:system 查看所有的 Java 系統(tǒng)屬性

六、環(huán)境變量屬性

所有環(huán)境變量都可以使用以 env. 開頭的 Maven 屬性引用。例如 ${env.JAVA_HOME} 指代了 JAVA_HOME 環(huán)境變量的值。

也可以通過命令行 mvn help:system 查看所有環(huán)境變量。

七、父級工程屬性

上級工程的 pom 中的變量用前綴 {parent.version}

Profile

profile 特性可以讓我們定義多個 profile，然后每個 profile 對應(yīng)不同的激活條件和配置信息，從而達(dá)到不同環(huán)境使用不同配置信息的效果。

profile 可以在以下幾個地方聲明：

• m.xml：這里聲明的 profile 只對當(dāng)前項目有效

• 用戶 settings.xml：.m2/settings.xml 中的 profile 對該用戶的 Maven 項目有效

• 全局 settings.xml：conf/settings.xml，對本機(jī)上所有 Maven 項目有效

示例：

<project>
??...
??<profiles>
????<profile>
??????<id>devid>
??????<properties>
????????<active.profile>devactive.profile>
????????<key1>value1key1>
????????<key2>value2key2>
??????properties>

??????
??????<activation>
????????<activeByDefault>trueactiveByDefault>
??????activation>
??????
??????<dependencies>
????????<dependency>
??????????<groupId>org.springframeworkgroupId>
??????????<artifactId>spring-contextartifactId>
??????????<version>3.2.4.RELEASEversion>
????????dependency>
??????<dependencies>
??????
??????<build>
????????<filters>
??????????<filter>../profile/test-pre.propertiesfilter>
????????filters>
??????build>
????profile>
??profiles>
??...
project>

源于：https://juejin.im/post/6844903839435341832

推薦文章

• 硬剛一周，3W字總結(jié)，一年的經(jīng)驗告訴你如何準(zhǔn)備校招！
  

• 今年的校招，Java 好拿 offer 嗎？
  

• 10月了，該聊聊今年秋招了！
  

• 聊聊在騰訊實習(xí)快一個月的感受
  

原創(chuàng)電子書
歷時整整一年總結(jié)的?Java 面試 + Java 后端技術(shù)學(xué)習(xí)指南，這是本人這幾年及校招的總結(jié)，各種高頻面試題已經(jīng)全部進(jìn)行總結(jié)，按照章節(jié)復(fù)習(xí)即可，已經(jīng)拿到了大廠offer。
原創(chuàng)思維導(dǎo)圖
掃碼或者微信搜?程序員的技術(shù)圈子?回復(fù)?面試?領(lǐng)取原創(chuàng)電子書和思維導(dǎo)圖。