maven完結版，入門到精通。

START

• author：空巷

• WeChat Applet(公衆號) ：Java空巷

• QQ： 2399014502

• Mail： [email protected]

• WeiBo : KongXiang_

• WeChat：

Maven

當沒有學Maven的時候，項目需要我們去手動自行構建，而且idea，eclipse，甚至一些其他開發工具的構建方式是不一樣的。那麼有沒有一種工具，可以幫助我們構建項目，無需手動構建，只需要通過配置即可。

Maven 功能

Maven 能夠幫助我們完成以下工作：

• 構建
• 文檔生成
• 統一管理jar包，自動導入jar及其依賴。
• 項目移植之後不需要安裝開發工具，只需要maven加命令就可以跑起來。
• 使我們的項目流水線成爲可能，只需要加簡單的命令我們就可以完成項目的編譯，打包，發佈等工作。

Maven的優勢

1. 優勢一： 相同的項目結構

使用Maven管理的Java 項目都有着相同的項目結構

• 有一個pom.xml 用於維護當前項目都用了那些jar包

• 所有的java代碼都放在 src/main/java

• 所有的測試代碼都放在src/test/java

2. 優勢二：統一維護jar包

比如說有3個Java 項目，這些項目都不是maven風格。那麼這3個項目，就會各自維護一套jar包。 而其中有些jar包是相同的。

而maven風格的項目，首先把所有的jar包都放在"maven倉庫“ 裏，然後哪個項目需要用到這個jar包，只需要給出jar包的名稱和版本號就行了。如下所示：

<dependencies>
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>4.0.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>javax.servlet.jsp</groupId>
            <artifactId>jsp-api</artifactId>
            <version>2.2</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

3. 優勢三：模塊劃分

平時我們開發項目時，一般都是一個項目就是一個工程。我們劃分模塊時，都是使用package來進行劃分。但是，當項目很大時，有很多子模塊時，即使是package來進行劃分，也是讓人眼花繚亂。此時可藉助Maven將一個項目拆分成多個工程，最好是一個模塊對應一個工程，利於分工協作。而且模塊之間還是可以發送消息的。

Maven的特點

• 項目遵循統一的規則

• 一個龐大且不斷增長的庫

• 可擴展，能夠輕鬆編寫 Java 或腳本語言的插件

• 項目信息的一致性站點 − 使用與構建過程相同的元數據，Maven 能夠生成一個網站或PDF，包括您要添加的任何文檔，並添加到關於項目開發狀態的標準報告中。
• 發佈管理和發佈單獨的輸出 − Maven 將不需要額外的配置，就可以與源代碼管理系統（如 Subversion 或 Git）集成，並可以基於某個標籤管理項目的發佈。它也可以將其發佈到分發位置供其他項目使用。Maven 能夠發佈單獨的輸出，如 JAR，包含其他依賴和文檔的歸檔，或者作爲源代碼發佈。
• 向後兼容性 − 您可以很輕鬆的從舊版本 Maven 的多個模塊移植到 Maven 3 中。
• 子項目使用父項目依賴時，正常情況子項目應該繼承父項目依賴，無需使用版本號，
• 並行構建 − 編譯的速度能普遍提高20 - 50 %。
• 更好的錯誤報告 − Maven 改進了錯誤報告，它爲您提供了 Maven wiki 頁面的鏈接，您可以點擊鏈接查看錯誤的完整描述。

Maven下載及其安裝

下載地址：http://maven.apache.org/

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-EYTbk0Yv-1591469800210)(C:\Users\dell\AppData\Roaming\Typora\typora-user-images\image-20200606112252539.png)]

Apache軟件基金會（也就是Apache Software Foundation，簡稱爲ASF），是專門爲支持開源軟件項目而辦的一個非盈利性組織。在它所支持的Apache項目與子項目中，所發行的軟件產品都遵循Apache許可證（Apache License）。

安裝及配置環境（學過Java的都會）

1. 解壓
2. 配置MAVEN_HOME
3. 配置 path，%MAVEN_HOME%\bin
4. cmd 執行mvn-v ，出現 maven 的版本號及配置成功。

Maven核心全局配置文件

去 Maven 安裝路徑下的 conf 文件夾下 用記事本（其他軟件）打開 settings.xml 文件

配置路徑(路徑是你自己的路徑，當你不配置這個jar包默認會往你的C：/…/.m2文件夾下下載)

<localRepository>D:/repository</localRepository>

配置阿里雲鏡像（當你需要下載 jar 時，系統默認會去 maven 中央倉庫去下載，國內訪問 下載會很慢，所以配置一個阿里雲鏡像，讓它去阿里雲倉庫去下載）

<mirrors>
  <mirror>
    <id>alimaven</id>
    <name>aliyun maven</name>
    <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
    <mirrorOf>central</mirrorOf>
  </mirror>
<mirrors>

配置全局編譯 jdk 版本

<profile>  
  <id>jdk-1.8</id>  
  <activation>  
  <activeByDefault>true</activeByDefault>  
  <jdk>1.8</jdk>  
   </activation>  
  <properties>  
    <maven.compiler.source>1.8</maven.compiler.source>  
    <maven.compiler.target>1.8</maven.compiler.target>  
    <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>  
  </properties>  
</profile>

Maven 的目錄

src                
    |--main
    	|--java     源代碼目錄
    	|--resources   資源目錄   
    |--test
    	|--java     測試代碼目錄
    	|--resources   測試資源目錄
|--target
    |--classes    編譯後的class文件目錄
    |--test-classes 編譯後的測試class文件目錄
pom.xml       Maven工程配置文件

pom.xml 的基本要求：

<?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>
    <!-- 公司或者組織的唯一標誌，並且配置時生成的路徑也是由此生成， 如com.xinzhi，maven會將該項目打成的jar包放本地路徑：/com/xinzhi -->
    <groupId>com.xinzhi</groupId>
 
    <!-- 項目的唯一ID，一個groupId下面可能多個項目，就是靠artifactId來區分的 -->
    <artifactId>project</artifactId>
 
    <!-- 版本號 -->
    <version>1.0</version>
</project>

Maven 生命週期

Maven生命週期就是描述了一個項目從源代碼到部署的整個週期（由以下幾個階段的序列組成）

Maven 有以下三個標準的生命週期：

• clean：項目清理的處理，就是我們經常做的，刪除out文件夾
• default(或 build)：項目部署的處理，進行項目編譯打包等工作
• site：項目站點文檔創建的處理，生成項目報告，站點，發佈站點

默認（default）的聲明週期包括以下階段

階段	處理	描述
驗證 validate	驗證項目	驗證項目是否正確且所有必須信息是可用的
編譯 compile	執行編譯	源代碼編譯在此階段完成
測試 Test	測試	使用適當的單元測試框架（例如JUnit）運行測試。
包裝 package	打包	創建Jar/war包如在 pom.xml 中定義提及的包
檢查 verify	檢查	對集成測試的結果進行檢查，以保證質量達標
安裝 install	安裝	安裝打包的項目到本地倉庫，以供其他項目使用
部署 deploy	部署	拷貝最終的工程包到遠程倉庫中，以共享給其他開發人員和工程

mvn install

此命令在執行安裝之前按順序（驗證（validate），編譯（compile），打包（package）等）執行每個默認生命週期階段。在這種情況下，您只需要調用最後一個構建階段來執行，安裝（install）。

mvn clean deploy

相同的命令可以在多模塊場景（即具有一個或多個子項目的項目）中使用。Maven遍歷每個子項目並執行清潔（clean），然後執行部署（deploy）（包括所有之前的構建階段步驟）。
注意：在我們開發階段，有一些生命週期的階段，比如驗證（validate）這些，基本很少用到。只要使用關鍵的幾
個基本能滿足需求。

Clean 生命週期

當我們執行 mvn post-clean 命令時，Maven 調用 clean 生命週期，它包含以下階段：

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

Maven的常用命令

命令	說明
mvn –version	顯示版本信息
mvn clean	清理項目生產的臨時文件,一般是模塊下的target目錄
mvn compile	編譯源代碼，一般編譯模塊下的src/main/java目錄
mvn package	項目打包工具,會在模塊下的target目錄生成jar或war等文件
mvn test	測試命令,或執行src/test/java/下junit的測試用例
mvn install	將打包的jar/war文件複製到你的本地倉庫中,供其他模塊使用
mvn deploy	將打包的文件發佈到遠程參考,提供其他人員進行下載依賴
mvn site	生成項目相關信息的網站
mvn dependency:tree	打印出項目的整個依賴樹
mvn archetype:generate	創建Maven的普通java項目
mvn tomcat:run	在tomcat容器中運行web應用

在idea中配置Maven

把畫紅線的東西全部配置成自己的。最後一個是倉庫，在你的其他盤找一個地方新建repository文件夾，自己要知道，選中，如果勾選不了就選擇都選override。

如果不選擇倉庫會把jar包下載至C：/Users/…/.m2/repository 文件下，不好維護，還佔用c盤空間。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-xPPDB1eI-1591469800213)(C:\Users\dell\AppData\Roaming\Typora\typora-user-images\image-20200606151914396.png)]

兩處都要配置，一個是當前項目的maven配置，一個是新建項目的maven配置。（我的idea是19版本的，和20版本的位置有差別，但設置都一致）

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-fNfAEiEh-1591469800215)(C:\Users\dell\AppData\Roaming\Typora\typora-user-images\image-20200606152011412.png)]

Maven依賴

管理包依賴是 Maven 核心功能之一，下面通過如何引入 jar 包；如何解析 jar 包依賴；包衝突是如何產生；如何解決包衝突；依賴管理解決什麼問題；什麼是依賴範圍；使用包依賴的最佳實踐等 6 個問題來介紹。

Maven 遠程倉庫：https://mvnrepository.com/

Maven 阿里雲遠程倉庫：https://maven.aliyun.com/mvn/search

如何引入 jar 包

在代碼開發時，如果需要使用第三方 jar 包提供的類庫，那麼需要在 pom.xml 加入該 jar 包依賴。

例如：使用 zookeeper client

<dependencies>
  <!-- https://mvnrepository.com/artifact/org.apache.hadoop/zookeeper -->
  <dependency>
      <groupId>org.apache.hadoop</groupId>
      <artifactId>zookeeper</artifactId>
      <version>3.3.1</version>
  </dependency>
</dependencies>

Maven 如何解析 jar 包依賴——傳遞依賴

如上所述，在 pom.xml 中引入 zookeeper jar 包依賴，當 Maven 解析該依賴時，需要引入的 jar 包不僅僅只有 zookeeper，還會有 zookeeper 內部依賴的 jar 包，還會有 zookeeper 內部依賴的 jar 包依賴的 jar 包…，依賴關係不斷傳遞，直至沒有依賴。

例如：上述 pom.xml 引入 zookeeper 依賴，實際引入的 jar 包有：

包衝突如何產生？

舉個🌰：假設 A->B->C->D1, E->F->D2，D1,D2 分別爲 D 的不同版本。
如果 pom.xml 文件中引入了 A 和 E 之後，按照 Maven 傳遞依賴原則，工程內需要引入的實際 Jar 包將會有：A B C D1 和 E F D2，因此 D1,D2 將會產生包衝突。

如何解決包衝突

Maven 解析 pom.xml 文件時，同一個 jar 包只會保留一個，這樣有效的避免因引入兩個 jar 包導致的工程運行不穩定性。

Maven 默認處理策略

• 最短路徑優先

Maven 面對 D1 和 D2 時，會默認選擇最短路徑的那個 jar 包，即 D2。E->F->D2 比 A->B->C->D1 路徑短 1。

• 最先聲明優先

如果路徑一樣的話，舉個🌰： A->B->C1, E->F->C2 ，兩個依賴路徑長度都是 2，那麼就選擇最先聲明

移除依賴

如果我們不想通過 A->B->->D1 引入 D1 的話，那麼我們在聲明引入 A 的時候將 D1 排除掉，這樣也避免了包衝突。

舉個🌰：將 zookeeper 的 jline 依賴排除

<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.3.1</version>
    <exclusions>
        <exclusion>
            <groupId>jline</groupId>
            <artifactId>jline</artifactId>
        </exclusion>
    </exclusions>
</dependency>

檢測包衝突工具

mvn dependency:help
mvn dependency:analyze
mvn dependency:tree
mvn dependency:tree -Dverbose

Maven依賴範圍

classpath （類路徑） 就是編譯好的 class 文件所在的路徑事實上，就是我們的類加載器（classloader） 就是去對應的 classpath 中加載 class 二進制文件。

maven項目：

maven工程會將 src/main/java 和 src/main/resources 文件夾下的文件全部打包在classpath中。運行時他們兩個的文件夾下的文件會被放在一個文件夾下。

maven 項目不同的階段引入到classpath中的依賴是不同的，例如：

• 編譯時 ，maven 會將與編譯相關的依賴引入classpath中
• 測試時 ，maven會將測試相關的的依賴引入到classpath中
• 運行時 ，maven會將與運行相關的依賴引入classpath中

而依賴範圍就是用來控制依賴於這三種classpath的關係。

scope標籤就是依賴範圍的配置

有些jar包（如selvlet-api）運行時其實是不需要的，因爲tomcat裏有，但編譯時是需要的，因爲編譯的時候沒有tomcat環境。

有些jar只在測試的時候才能用到。比如junit，真是運行不需要的。

有些jar運行，測試時必須要有，編譯時不需要，如jdbc驅動，編譯時用的都是jdk中的接口，運行時我們才使用反射註冊了驅動。

類似以上的這些jar包不是說使用默認的compile一定不行，但是設置成合適的範圍更好，當然有事會有問題，比如你引入的servlet-api和tomcat自帶的不一樣，就會出問題。

編譯依賴範圍（compile）

如果沒有指定，就會默認使用該依賴範圍。使用此依賴範圍的maven依賴，對於編譯 測試 運行三種的classpath都有效。

舉個簡單的例子，假如項目中有 fastjson 的依賴，那麼 fastjson 不管是在編譯，測試，還是運行都會被用到，因此 fastjson 必須是編譯範圍（構件默認的是編譯範圍，所以依賴範圍是編譯範圍的無須顯示指定）

<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>fastjson</artifactId>
  <version>1.2.68</version>
</dependency>

測試依賴範圍(test)

使用此依賴範圍的Maven依賴，只對於測試的classpath有效，在編譯主代碼或者運行主代碼的時候都無法依賴此類依賴。典型的例子是jUnit,它只有在編譯測試代碼及運行測試代碼的時候纔有效。所以它的依賴範圍是測試，因此它的依賴範圍需要顯示指定爲
test,當然不顯示指定依賴範圍也不會報錯，但是該依賴會被加入到編譯和運行的classpath中,造
成不必要的浪費 。

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.7</version>
  <scope>test</scope>
</dependency>

已提供依賴範圍(provided)

使用此依賴範圍的maven依賴，對於編譯和測試classpath有效，但在運行時無效。典型的例子是servlet-api，編譯和測試項目的時候需要該依賴，但在運行的時候，由於容器已經提供，就不需要maven重複地引入一遍。打包的時候可以不用包進去，別的設施會提供。事實上該依賴理論上可以參與編譯，測試，運行等週期。相當於compile，但是打包階段做了exclude操作

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>4.0.1</version>
  <scope>provided</scope>
</dependency>

運行時依賴範圍(runtime)

使用此依賴範圍的maven依賴，對於測試和運行classpath有效，但在編譯主代碼時無效。典型的例子是JDBC驅動實現，項目主代碼的編譯只需要jdk提供的jdbc的接口，只有在執行測試或者運行測試的時候才需要實現上述接口的jdbc的驅動。

<dependency>
  <groupId>mysql</groupId>
  <artifactId>mysql-connector-java</artifactId>
  <version>5.1.25</version>
  <scope>runtime</scope>
</dependency>

系統依賴範圍（system）

從參與度來說，和provided相同，不過被依賴項不會從maven倉庫下載，而是從本地文件系統拿。需要添加systemPath的屬性來定義路徑，該依賴與三種範圍的classpath

和provided依賴範圍完全一致。可能造成不可移植，謹慎使用。

導入依賴範圍（import）

該依賴範圍不會對三種classpath產生實際的影響。只有在dependencyManagement下才有效果。

Maven聚合和繼承（分佈式開發必須使用）

Maven的聚合特性可以幫助我們把項目的多個模塊聚合在一起，使

用一條命令進行構建，即一條命令實現構建多個項目；

Maven的繼承特性可以將各個模塊相同的依賴和插件配置提取出

來，在簡化POM的同時還可以促進各個模塊配置的一致性。

聚合模塊（父模塊）的打包方式必須爲pom，否則無法完成構建。

在聚合多個項目時，如果這些被聚合的項目中需要引入相同的Jar，那麼可以將這些Jar寫入父pom中，各個子項目繼承該pom即可。，父模塊的打包方式必須爲pom，否則無法構建項目。

<packaging>pom</packaging>

通過在各個子模塊中配置來表明其繼承與哪一個父模塊：

<parent>
  <artifactId>parent</artifactId>
  <groupId>org.example</groupId>
  <version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>childern-two</artifactId>

可以被繼承的POM元素如下：

• groupId：項目組ID，項目座標的核心元素
• version：項目版本，項目座標的核心因素
• properties：自定義的Maven屬性 一般用於同一制定各個依賴的版本號
• dependencies：項目的依賴配置 公共的依賴
• dependencyManagement：項目的依賴管理配置
• repositories：項目的倉庫配置
• build：包括項目的源碼目錄配置、輸出目錄配置、插件配置、插件管理配置等

一些對項目的描述

• description：項目的描述信息
• organization：項目的組織信息
• inceptionYear：項目的創始年份
• url：項目的URL地址
• developers：項目的開發者信息
• contributors：項目的貢獻者信息
• distributionManagement：項目的部署配置
• issueManagement：項目的缺陷跟蹤系統信息
• ciManagement：項目的持續集成系統信息
• scm：項目的版本控制系統
• malilingLists：項目的郵件列表信息
• reporting：包括項目的報告輸出目錄配置、報告插件配置等

聚合和繼承的關係

雖然聚合模塊和父模塊經常合二爲一，但是聚合和繼承是兩個不同的概念，其實是沒有什麼關係的。

聚合模塊知道它聚合了哪些模塊，但是被聚合的模塊不知道聚合模塊的存在；

父模塊不知道子模塊的存在，但是子模塊都必須知道自己的父模塊是誰。

可以用下圖來表示這兩個不同的概念：

Maven插件

Maven插件介紹

Maven 實際上是一個依賴插件執行的框架，每個任務實際上是由插件完成。Maven 插件通常被用來：

• 打包jar 文件
• 創建 war 文件
• 編譯代碼文件
• 代碼單元測試
• 創建工程文檔
• 創建工程報告

插件通常提供了一個目標的集合，並且可以使用下面的語法執行：

mvn [plugin-name]:[goal-name]

例如，一個 Java 工程可以使用 maven-compiler-plugin 的 compile-goal 編譯，使用以下命令：

mvn compiler:compile

maven-compiler-plugin

設置maven編譯的jdk版本，maven3默認用jdk1.5，maven2默認用jdk1.3

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.1</version>
    <configuration>
        <source>1.8</source> <!-- 源代碼使用的JDK版本 -->
        <target>1.8</target> <!-- 需要生成的目標class文件的編譯版本 -->
        <encoding>UTF-8</encoding><!-- 字符集編碼 -->
    </configuration>
</plugin>

tomcat插件

<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <configuration>
        <port>8080</port>
        <uriEncoding>UTF-8</uriEncoding>
        <path>/xinzhi</path>
        <finalName>xinzhi</finalName>
    </configuration>
</plugin>

點擊idea右側的maven我們可以方便的看到我們使用了什麼插件，並可以點擊執行相應的命令。

通過插件和命令我們都可以啓動項目了，都不用部署到tomcat裏了。

war包打插件

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <warName>test</warName>
    <webResources>
      <resource>
        <directory>src/main/webapp/WEB-INF</directory>
        <filtering>true</filtering>
        <targetPath>WEB-INF</targetPath>
        <includes>
          <include>web.xml</include>
        </includes>
      </resource>
    </webResources>
  </configuration>
</plugin>

POM文件

基礎配置

<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.0http://maven.apache.org/xsd/maven
-4.0.0.xsd">
  <!-- 模型版本。maven2.0必須是這樣寫，現在是maven2唯一支持的版本 -->
  <modelVersion>4.0.0</modelVersion>
  <!-- 公司或者組織的唯一標誌，並且配置時生成的路徑也是由此生成， 如com.xinzhi，maven會將該項目打
成的jar包放本地路徑：/com/xinzhi/ -->
  <groupId>com.xinzhi</groupId>
  <!-- 本項目的唯一ID，一個groupId下面可能多個項目，就是靠artifactId來區分的 -->
  <artifactId>test</artifactId>
  <!-- 本項目目前所處的版本號 -->
  <version>1.0.0-SNAPSHOT</version>
 
  <!-- 打包的機制，如pom,jar, war，默認爲jar -->
  <packaging>jar</packaging>
  <!-- 爲pom定義一些常量，在pom中的其它地方可以直接引用 使用方式 如下 ：${file.encoding} -->
  <!-- 常常用來整體控制一些依賴的版本號 -->
  <properties>
    <file.encoding>UTF-8</file.encoding>
    <java.source.version>1.8</java.source.version>
    <java.target.version>1.8</java.target.version>
  </properties>
 
  <!-- 定義本項目的依賴關係，就是依賴的jar包 -->
  <dependencies>
    <!-- 每個dependency都對應這一個jar包 -->
    <dependency>
      <!--一般情況下，maven是通過groupId、artifactId、version這三個元素值（俗稱座標）來檢
索該構件， 然後引入你的工程。如果別人想引用你現在開發的這個項目（前提是已開發完畢併發布到了遠程倉庫），-
->
      <!--就需要在他的pom文件中新建一個dependency節點，將本項目的groupId、artifactId、
version寫入， maven就會把你上傳的jar包下載到他的本地 -->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <!-- 依賴範圍 -->
      <scope>complie</scope>
      <!-- 設置 依賴是否可選，默認爲false,即子項目默認都繼承。如果爲true,
        則子項目必需顯示的引入 -->
      <optional>false</optional>
     
      <!-- 依賴排除-->
      <exclusions>
        <exclusion>
          <groupId>org.slf4j</groupId>
          <artifactId>slf4j-api</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>
 ...
</project>

資源處理配置

<!-- 處理資源被過濾問題 -->
<build>
  <resources>
    <resource>
      <directory>src/main/java</directory>
      <includes>
        <include>**/*.properties</include>
        <include>**/*.xml</include>
      </includes>
      <filtering>false</filtering>
    </resource>
    <resource>
      <directory>src/main/resources</directory>
      <includes>
        <include>**/*.properties</include>
        <include>**/*.xml</include>
      </includes>
      <filtering>false</filtering>
    </resource>
  </resources>
</build>