Maven入門，讀完這篇就夠了
Maven 項目生命周期
Maven從項?的三個不同的?度，定義了三套?命周期，三套?命周期是相互獨?的，它們之間不會相互影響。
圖片
- 清理?命周期(Clean Lifecycle)：該?命周期負責清理項?中的多余信息，保持項?資源和代碼的整潔性。?般拿來清空directory(即?般的target)?錄下的?件。
- 默認構建?命周期(Default Lifeclyle)：該?命周期表示這項?的構建過程，定義了?個項?的構建要經過的不同的階段。
- 站點管理?命周期(Site Lifecycle)：向我們創建?個項?時，我們有時候需要提供?個站點，來介紹這個項?的信息，如項?介紹，項?進度狀態、項?組成成員，版本控制信息，項?javadoc索引信息等等。站點管理?命周期定義了站點管理過程的各個階段
常用命令
常用打包命令
mvn clean package -Dmaven.test.skip=true -- 跳過單測打包
mvn clean install -Dmaven.test.skip=true -- 跳過單測打包，并把打好的包上傳到本地倉庫
mvn clean deploy -Dmaven.test.skip=true -- 跳過單測打包，并把打好的包上傳到遠程倉庫其他命令
mvn -v //查看版本
mvnarchetype:create //創建 Maven 項目
mvncompile //編譯源代碼
mvntest-compile //編譯測試代碼
mvntest //運行應用程序中的單元測試
mvnsite //生成項目相關信息的網站
mvnpackage //依據項目生成 jar 文件
mvnpackage-PprofileName //指定profile進行打包,依據項目生成 jar 文件
mvninstall //在本地 Repository 中安裝 jar
mvn-Dmaven.test.skip=true //忽略測試文檔編譯
mvnclean //清除目標目錄中的生成結果
mvncleancompile //將.java類編譯為.class文件
mvncleanpackage //進行打包
mvncleantest //執行單元測試
mvncleandeploy //部署到版本倉庫
mvncleaninstall //使其他項目使用這個jar,會安裝到maven本地倉庫中
mvnarchetype:generate //創建項目架構
mvndependency:list //查看已解析依賴
mvndependency:treecom.xx.xxx //看到依賴樹
mvndependency:analyze //查看依賴的工具
mvnhelp:system //從中央倉庫下載文件至本地倉庫
mvnhelp:active-profiles //查看當前激活的profiles
mvnhelp:all-profiles //查看所有profiles
mvnhelp:effective-pom //查看完整的pom信息標簽解釋
常用標簽詳解
<!-- project 是根標簽-->
<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">
<!--指定父項目的坐標。如果項目中沒有規定某個元素的值，那么父項目中的對應值即為項目的默認值。 坐標包括group ID，artifact ID和 version。-->
<parent>
<!--繼承的父項目的構件標識符-->
<artifactId>maventest</artifactId>
<!--繼承的父項目的全球唯一標識符-->
<groupId>com.seven</groupId>
<!--繼承的父項目的版本:大版本.次版本.小版本 ;snapshot快照 alpha內部測試 beta公測 release穩定 GA正式發布-->
<version>1.0.0-SNAPSHOT</version>
<!-- 父項目的pom.xml文件的相對路徑。相對路徑允許你選擇一個不同的路徑。默認值是../pom.xml。Maven首先在構建當前項目的地方尋找父項 目的pom，其次在文件系統的這個位置（relativePath位置），然后在本地倉庫，最后在遠程倉庫尋找父項目的pom。-->
<relativePath/>
</parent>
<!-- 當前項目的標識 -->
<!--項目的全球唯一標識符，通常使用全限定的包名區分該項目和其他項目。并且構建時生成的路徑也是由此生成， 如com.mycompany.app生成的相對路徑為：/com/mycompany/app-->
<groupId>com.seven.ch</groupId>
<!-- 構件的標識符，它和group ID一起唯一標識一個構件。換句話說，你不能有兩個不同的項目擁有同樣的artifact ID和groupID；在某個特定的group ID下，artifact ID也必須是唯一的-->
<artifactId>Question8_1</artifactId>
<!--項目產生的構件類型，例如jar、war、ear、pom。插件也可以創建自己的構件類型，所以前面列的不是全部構件類型-->
<packaging>jar</packaging>
<!--項目當前版本，格式為:主版本.次版本.增量版本-限定版本號-->
<version>1.0-SNAPSHOT</version>
<!-- 項目 描述名-->
<name></name>
<!--項目主頁的URL, Maven產生的文檔用-->
<url></url>
<!-- 項目的詳細描述, Maven 產生的文檔用。-->
<description></description>
<!-- 集合多個子模塊，在父中設置-->
<modules></modules>
<!--指定了當前的pom的版本-->
<modelVersion>4.0.0</modelVersion>
<!--在列的項目構建profile，如果被激活，會修改構建處理；一般在子pom中設置-->
<profiles>
<!--根據環境參數或命令行參數激活某個構建處理-->
<profile>
<id>betanoah</id>
<properties>
<deploy.type>betanoah</deploy.type>
</properties>
</profile>
</profiles>
<!--定義標簽，一般在父pom中設置-->
<properties>
<!-- 自定義便簽，設置依賴版本 -->
<java_target_version>11</java_target_version>
<java_source_version>11</java_source_version>
<junit.junit>4.12</junit.junit>
<spring-boot.version>2.6.6</spring-boot.version>
</properties>
<!-- 繼承自該項目的所有子項目的默認依賴信息。這部分的依賴信息不會被立即解析,而是當子項目聲明一個依賴（必須描述group ID和 artifact ID信息），如果group ID和artifact ID以外的一些信息沒有描述，則通過group ID和artifact ID 匹配到這里的依賴，并使用這里的依賴信息。-->
<!-- 一般在父pom文件里配置 -->
<dependencyManagement>
<dependencies>
<!--參見dependencies/dependency元素-->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
//...
</dependencies>
</dependencyManagement>
<!-- 依賴列表，一般只在子pom文件里配置，父pom文件只做依賴的版本管理 -->
<dependencies>
<dependency>
<!-- 指定坐標從而知道依賴的是哪個項目-->
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<!-- 這個類的依賴范圍-->
<scope></scope>
<!-- 設置依賴是否可選 默認false 是默認繼承-->
<optional></optional>
<!-- 排除依賴傳遞列表-->
<exclusions>
<exclusion></exclusion>
</exclusions>
</dependency>
</dependencies>
<!-- 插件列表-->
<build>
<plugins></plugins>
</build>
</project>依賴管理
Maven項目，依賴，構建配置，以及構件：所有這些都是要建模和表述的對象。這些對象通過一個名為項目對象模型(Project Object Model, POM)的XML文件描述。
POM是Maven項目管理和構建的核心文件，它通常是一個名為pom.xml的XML文件。POM文件包含了項目的所有配置信息，Maven通過這些信息來構建項目、管理依賴以及執行其他構建任務。
這個POM告訴Maven它正處理什么類型的項目，如何修改默認的行為來從源碼生成輸出。同樣的方式，一個Java Web應用有一個web.xml文件來描述，配置，及自定義該應用，一個Maven項目則通過一個 pom.xml 文件定義。該文件是Maven中一個項目的描述性陳述；也是當Maven構建項目的時候需要理解的一份“地圖”。
坐標詳解
坐標，其實就是從眾多jar包中找到需要的那個jar包
傳遞性依賴
先考慮一個基于Spring Framework 的項目，如果不使用Maven, 那么在項目中就需要手動 下載相關依賴。由于Spring Framework 又會依賴于其他開源類庫，因此實際中往往會下載一個很大的如 spring-framework-2.5.6-with-dependencies.zip 的包，這里包含了所有Spring Framework 的 jar包，以及所有它依賴的其他 jar包。這么做往往就引入了很多不必要的依賴。另一種做法是只下載 spring-framework-2.5.6.zip 這樣一個包，這里不包含其他相關依賴，到實際使用的時候，再根據出錯信息，或者查詢相關文檔，加入需要的其他依賴。
Maven 的傳遞性依賴機制可以很好地解決這一問題。
傳遞性依賴就是，當項目A依賴于B，而B又依賴于C的時候，自然的A會依賴于C，這樣Maven在建立項目A的時候，會自動加載對C的依賴。
groupId
<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus-indexer</artifactId>
<version>2.0.0<Nersion>
<packaging>jar<packaging>這是 nexus-indexer 的坐標定義， nexus-indexer 是一個對Maven 倉庫編纂索引并提供搜索功能的類庫，它是 Nexus 項目的一個子模塊。后面會詳細介紹 Nexus。上述代碼片段中，其坐標分別為 groupld:org.sonatype.nexus、artifactld:nexus-indexer、version:2.0.0、packaging: jar, 沒有 classifier。下面詳細解釋一下各個坐標元素：
- groupId：定義當前 Maven 項目隸屬的實際項目。首先， Maven 項目和實際項目不一定是一對一的關系。比如 Spring Framework 這一實際項目，其對應的 Maven 項目會有很多，如 spring-core、spring-context 等。這是由于Maven 中模塊的概念，因此，一個實際項目往往會被劃分成很多模塊。其次， groupId不應該對應項目隸屬的組織或公司。原因很簡單，一個組織下會有很多實際項目，如果 groupId 只定義到組織級別， 而后面我們會看到，artifactId 只能定義Maven 項目(模塊), 那么實際項目這個層將難以定義。最后， groupId 的表示方式與Java包名的表示方式類似，通常與域名反向一一對應。上例中， groupId 為 org.sonatype.nexus, org.sonatype 表示 Sonatype 公司建立的一 個非盈利性組織，nexus 表示 Nexus 這一實際項目，該 groupId 與域名 nexus.sonatype.org 對應。
- artifactId：該元素定義實際項目中的一個Maven項目(模塊), 推薦的做法是使用實際項目名稱作為 artifactId 的前綴。比如上例中的 artifactId 是 nexus-indexer, 使用了實際項目名 nexus 作為前綴，這樣做的好處是方便尋找實際構件。在默認情況下， Maven生成的構件，其文件名會以 artifactId 作為開頭，如 nexus-indexer-2.0.0.jar, 使用實際項目名稱作為前綴之后，就能方便從一個 lib文件夾中找到某個項目的一組構件。考慮有5個項目，每個項目都有一個 core模塊，如果沒有前綴，我們會看到很多 core-1.2.jar這樣的文件，加上實際項目名前綴之后，便能很容易區分 foo-core-1.2.jar、bar-core-1.2.jar … … 。
- version：該元素定義Maven 項目當前所處的版本，如上例中 nexus-indexer 的版本是 2.0.0。需要注意的是， Maven 定義了一套完整的版本規范，以及快照 (SNAPSHOT)的概念。
- packaging：該元素定義 Maven 項目的打包方式。首先，打包方式通常與所生成構件的文件擴展名對應， 如上例中 packaging 為 jar, 最終文件名為 nexus-indexer-2.0.0.jar, 而使用 war 打包方式的Maven 項目，最終生成的構件會有一個 .war 文件， 不過這不是絕對的。其次，打包方式會影響到構建的生命周期，比如 jar打包和 war打包會使用不同的命令。最后，當不定義 packaging 的時候，Maven 會使用默認值 jar。
- classifier：該元素用來幫助定義構建輸出的一些附屬構件。附屬構件與主構件對應， 如上例中的主構件是 nexus-indexer-2.0.0.jar, 該項目可能還會通過使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources. jar 這樣一些附屬構件，其包含了Java 文檔和源代碼。這時候， javadoc和 sources 就是這兩個附屬構件的classifier。這樣，附屬構件也就擁有了自己唯一的坐標。還有一個關于classifier 的典型例子是 TestNG, TestNG 的主構件是基于Java 1.4平臺的，而它又提供了一個classifier為 jdk5 的附屬構件。注意，不能直接定義項目的 classifier, 因為附屬構件不是項目直接默認生成的，而是由附加的插件幫助生成。
上述5個元素中， groupId、artifactId、version 是必須定義的， packaging是可選的(默認為jar), 而 classifier是不能直接定義的。
同時，項目構件的文件名是與坐標相對應的， 一般的規則為 artifactId-version [-classifier].packaging, [-classifier] 表示可選。比如上例 nexus-indexer 的主構件為 nexus-indexer-2.0.0.jar, 附屬構件有 nexus-indexer-2.0.0-javadoe.jar。這里還要強調的一點是，packaging 并非一定與構件擴展名對應，比如 packaging 為 maven-plugin 的構件擴展名為 jar。
此外， Maven 倉庫的布局也是基于Maven 坐標，這一點會在介紹 Maven 倉庫的時候詳細解釋。同樣地，理解清楚 Maven 坐標之后，我們就能開始討論Maven 的依賴管理了。
dependencies
在dependencies標簽中添加需要添加的jar對應的Maven坐標
<project>
...
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<type>...</type>
<scope>...</scope>
<optional>...</optional>
<exclusions>
<exclusion>
...
</exclusion>
</exclusions>
</dependency>
</dependencies>
...
</project>根元素 project 下的 dependencies 可以包含一個或者多個 dependency 元素，以聲明一個或者多個項目依賴。每個依賴可以包含的元素有：
- groupId 、artifactId 和 version：依賴的基本坐標，對于任何一個依賴來說，基本坐標是最重要的， Maven 根據坐標才能找到需要的依賴。
- type：依賴的類型，對應于項目坐標定義的 packaging 。大部分情況下，該元素不必聲明，其默認值為jar。
- scope：依賴的范圍。
- optional：標記依賴是否可選。
- exclusions：用來排除傳遞性依賴。
大部分依賴聲明只包含基本坐標，然而在一些特殊情況下，其他元素至關重要。
scope
依賴范圍 | 編譯有效 | 測試有效 | 運行時有效 | 打包有效 | 例子 |
Complie | √ | √ | √ | √ | spring-core |
test | × | √ | × | × | Junit |
provided | √ | √ | × | × | servlet-api,lombok |
runtime | × | √ | √ | √ | JDBC驅動 |
system | √ | √ | × | × | 本地maven倉庫之外的類庫 |
import | N/A | N/A | N/A | N/A | BOM文件 |
optional
假設有這樣一個依賴關系，項目A 依賴于項目B, 項目B 依賴于項目X 和Y, B 對于X 和Y 的依賴都是可選依賴：A->B、B->X(可選)、B->Y(可選)。根據傳遞性依賴的定義，如果所有這三個依賴的范圍都是 compile, 那么 X、Y 就是A 的 compile 范圍傳遞性依賴。然而，由于這里X、Y 是可選依賴，依賴將不會得以傳遞。換句話說， X、Y 將不會對 A有任何影響，如下圖所示。
圖片
為什么要使用可選依賴這一特性呢? 可能項目B 實現了兩個特性，其中的特性一依賴于X, 特性二依賴于Y, 而且這兩個特性是互斥的，用戶不可能同時使用兩個特性。比如 B 是一個持久層隔離工具包，它支持多種數據庫，包括 MySQL、PostgreSQL 等，在構建這個工具包的時候，需要這兩種數據庫的驅動程序，但在使用這個工具包的時候，只會依賴一種數據庫。
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xiaoshan.mvnbook</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.10</version>
<optional>true</optional>
</dependency>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.4-701.jdbc3</version>
<optional>true</optional>
</dependency>
</dependencies>
</project>上述 XML代碼片段中，使用<optional>元素表示 mysql-connector-java 和 postgresql 這兩個依賴為可選依賴，它們只會對當前項目產生影響，當其他項目依賴于這個項目的時候，這兩個依賴不會被傳遞。
因此，當項目A依賴于項目B的時候，如果其實際使用基于MySQL數據庫，那么在項目A中就需要顯式地聲明 mysgl-connectorjava這一依賴，見以下代碼清單。
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xiaoshan.mvnbook</groupId>
<artifactId>project-a</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>com.xiaoshan.mvnbook</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.10</version>
</dependency>
</dependencies>
</project>但是實際上，在理想的情況下，是不應該使用可選依賴的。 使用可選依賴的原因是某一個項目實現了多個特性，在面向對象設計中，有個單一職責性原則，意指一個類應該只有一項職責，而不是糅合太多的功能。
這個原則在規劃 Maven 項目的時候也同樣適用。在上面的例子中，更好的做法是為MySQL 和 PostgreSQL分別創建一個 Maven 項目 ， 基于同樣的 groupId 分配不同的artifactId, 如 com.xiaoshan. mvnbook:project-b-mysql 和 com.xiaoshan. mvnbook:project-b-postgresgl, 在各自的 POM 中聲明對應的JDBC 驅動依賴，而且不使用可選依賴，用戶則根據需要選擇使用 pro-ject-b-mysql 或者 project-b-postgresql。 由于傳遞性依賴的作用，就不用再聲明JDBC 驅動依賴。
排除依賴exclusions
假設有這樣一種依賴關系，A->B->C，這個時候由于某些原因，不需要對C的依賴，但是又必須要對B的依賴，針對這種情況，可以在添加A對B的依賴時申明不需要引進B對C的依賴。具體做法如下：
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-spring-plugin</artifactId>
<version>2.5.20</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
</exclusions>
</dependency>依賴沖突
沖突產生的根本原因
圖片
由于傳遞依賴的原因，a會通過b引入c的依賴，也會通過d引入c的依賴，因此出現了沖突
依賴關系 | 實例 |
直接依賴 | a和b的依賴關系 |
間接依賴 | a和c的依賴關系 |
依賴沖突的解決方案
路徑最近者優先
Maven 依賴調解 (Dependency Mediation) 的第一原則是：路徑最近者優先
項目A 有這樣的依賴關系： A->B->C->X(1.0)、A->D->X(2.0)，根據路徑最近者優先原則，X(1.0) 的路徑長度為 3 , 而 X(2.0) 的路徑長度為2, 因此X(2.0) 會被解析使用。
第一優先聲明
但是如果路徑長度一樣呢，如A->B->Y(1.0)、A-> C->Y(2.0)
從 Maven 2.0.9開始，第二原則是：第一優先聲明，也就是誰先定義就使用誰的
覆寫優先原則
? POM 內聲明的依賴優先于? POM 中聲明的依賴。
- 找到 Maven 加載的 Jar 包版本，使? mvn dependency:tree 查看依賴樹，根據依賴原則來調整依賴在POM ?件的聲明順序。
- 發現了沖突的包之后，剩下的就是選擇?個合適版本的包留下，如果是傳遞依賴的包正確，那么把顯示依賴的包exclude掉。如果是某?個傳遞依賴的包有問題，那需要?動把這個傳遞依賴execlude掉
如何處理無法拉取的jar包
注：本文中所有解決方案均使用IDEA操作
設置了離線工作
有些用戶的IDEA中可能設置了離線工作，這項設置會讓IDEA無法連接網絡，自然也無法下載所需資源了。要修改這一設置，具體操作如下：
點擊File>>Settings，在彈出的菜單中選擇Build,Execution,Deployment >> Build Tools >> Maven，然后查看頁面中的Work Offline項是否處于勾選狀態，如果是，則IDEA無法聯網，應該取消勾選。如下圖所示：
圖片
配置文件問題
設置maven的 settings.xml文件的鏡像 為阿里云鏡像
<mirror>
<id>alimaven-new</id>
<name>aliyun maven</name>
<url>https://maven.aliyun.com/repository/central</url>
<mirrorOf>central</mirrorOf>
</mirror>
<mirror>
<id>aliyun-public</id>
<mirrorOf>central</mirrorOf>
<name>aliyun public</name>
<url>https://maven.aliyun.com/repository/public</url>
</mirror>手動下載
到以下網站尋找所需要的jar包：
https://repo.maven.apache.org/maven2/
根據控制臺輸出信息可知，需要的 com.github.spotbugs:spotbugs-maven-plugin:4.2.2
圖片
找到所需的jar包，進行下載
圖片
并放到本地的maven倉庫中。
