以前的日子

以前我們寫代碼時(shí)，jar包都默認(rèn)放在一個(gè)叫 /lib 的目錄下，然后把該目錄設(shè)置為classpath可以讀取到的目錄，如下圖所示：

某一天我們新加了一個(gè)功能，需要用到一個(gè)比較古老的 z.jar 包，這時(shí)我們到網(wǎng)上去各種搜索，由于比較罕見，最終在某個(gè) xxx軟件園 中找到了他。然后我們把 z.jar 包拷貝到 /lib 目錄下：

這時(shí)運(yùn)行后報(bào)了一堆的錯(cuò)，原因是 z.jar 包有很多的依賴項(xiàng)，分別是 z1.jar , z2.jar , z3.jar。這時(shí)的你是否有種想要罵人的沖動(dòng)？但是沖動(dòng)歸沖動(dòng)，代碼還是要寫，jar包還是要找，自己挖的坑，哭著也要填完啊。

歷經(jīng)千難萬險(xiǎn)，終于在1個(gè)博客中找到了 z1.jar , z2.jar , z3.jar 的下載鏈接，但是需要支付積分才能下載。。為了得到這些jar包，我們又注冊(cè)了一個(gè)賬號(hào)，發(fā)了幾個(gè)評(píng)論，賺到足夠的積分后，終于把那三個(gè)jar包下載下來了。然后趕緊把他們拷貝到 /lib 下去：

湊夠了jar包之后，再次運(yùn)行項(xiàng)目，終于能成功運(yùn)行了，真是謝天謝地！

過了半個(gè)月，老板說我們 項(xiàng)目A 非常不錯(cuò)，現(xiàn)在我們準(zhǔn)備再啟動(dòng)一個(gè) 項(xiàng)目B 作為他的兄弟項(xiàng)目。這時(shí)你開始搭建 項(xiàng)目B 的框架了，把所有需要用到的jar包從 項(xiàng)目A 拷貝到 項(xiàng)目B 中：

從此你又開始了打怪升級(jí)的日子了。

現(xiàn)在的日子

隨著科技的發(fā)展，改革開放的浪潮席卷了大地，也席卷了IT界，一大堆生產(chǎn)力工具被創(chuàng)造出來了，俗話說的好，工欲善其事必先利其器。有了好的生產(chǎn)力工具，要做的事必定是事半功倍！而 Maven 就是一種為了解放我們程序猿的生產(chǎn)力工具。

程序猿在日常工作中需要用到大量的jar包，有的是框架包如：netty，sentinel等，有的是工具包如：hutool，有的是公司內(nèi)部的私有包如：xx-framework等等。

一個(gè)項(xiàng)目中可能充斥著各種各樣的jar包，如果我們用手工的方式去一個(gè)一個(gè)的管理的話，那樣就會(huì)迷失在jar包的海洋里，這時(shí)我們通過 Maven 這種管理jar包的工具來幫助我們解決這個(gè)繁瑣又棘手的問題，可以讓我們專心于自己的功能與業(yè)務(wù)。

其實(shí) Maven 是一套軟件工程管理和整合工具。他有很多的功能包括但不限于以下幾點(diǎn)：

工程的創(chuàng)建、構(gòu)建、測(cè)試依賴的管理倉庫的管理自動(dòng)化部署。。。

我們?nèi)粘Ｖ杏玫淖疃嗟目赡芫褪枪こ膛c依賴的管理了，其他的用到的頻率不多。

有了 Maven 之后，我們：

不需要為每個(gè)項(xiàng)目都創(chuàng)建一個(gè) /lib 目錄用來存放各種jar包了不需要為到哪去尋找我需要的jar包而發(fā)愁了不需要為引用的jar包去尋找他所依賴的jar包了。。。

結(jié)構(gòu)

下面是一個(gè)典型的maven項(xiàng)目的結(jié)構(gòu)圖：

倉庫

在 Maven 的術(shù)語中，倉庫是一個(gè)位置(place)，例如目錄，可以存儲(chǔ)所有的工程 jar 文件、library jar 文 件、插件或任何其他的工程指定的文件。

嚴(yán)格意義上說，Maven 只有兩種類型的倉庫:

本地(local)遠(yuǎn)程(remote)

本地倉庫

Maven 的本地倉庫是機(jī)器上的一個(gè)文件夾。它在你第一次運(yùn)行任何 maven 命令的時(shí)候創(chuàng)建。

Maven 的本地倉庫保存你的工程的所有依賴(library jar、plugin jar 等)。當(dāng)你運(yùn)行一次 Maven 構(gòu)建時(shí)，Maven 會(huì)自動(dòng)下載所有依賴的 jar 文件到本地倉庫中。它避免了每次構(gòu)建時(shí)都引用存放在遠(yuǎn)程倉庫上的依賴文件。

Maven 的本地倉庫默認(rèn)被創(chuàng)建在 ${user.home}/.m2/repository 目錄下。要修改默認(rèn)位置，只要在 settings.xml 文件中定義另一個(gè)路徑即可，例如：

/anotherDirectory/.m2/respository

遠(yuǎn)程倉庫

Maven 的遠(yuǎn)程倉庫可以是任何其他類型的存儲(chǔ)庫，可通過各種協(xié)議，例如 file：//和 http：// 來訪問。

這些存儲(chǔ)庫可以是由第三方提供的可供下載的遠(yuǎn)程倉庫，例如Maven 的中央倉庫(central repository)：

repo.maven.apache.org/maven2

uk.maven.org/maven2

也可以是在公司內(nèi)的FTP服務(wù)器或HTTP服務(wù)器上設(shè)置的內(nèi)部存儲(chǔ)庫，用于在開發(fā)團(tuán)隊(duì)和發(fā)布之間共享私有的 artifacts。

中央倉庫

Maven 的中央倉庫是 Maven 社區(qū)維護(hù)的，里面包含了大量常用的庫，我們可以直接引用，但是前提是我們的項(xiàng)目能夠訪問外網(wǎng)。

私有倉庫

除了 Maven 的中央倉庫外，還有一種就是私有倉庫，這種倉庫通常都是企業(yè)內(nèi)部創(chuàng)建的一個(gè)私有庫，用于一些內(nèi)部jar包的維護(hù)與共享。由于網(wǎng)絡(luò)原因和鑒于安全性的考慮，很多公司的內(nèi)外網(wǎng)是隔離的，要想直接訪問中央倉庫是不可能的，并且直接把內(nèi)部資源暴露在互聯(lián)網(wǎng)上也是非常危險(xiǎn)的，所以這時(shí)就需要?jiǎng)?chuàng)建一個(gè)私有庫。

那這些倉庫之間的關(guān)系是怎樣的呢？或者說一個(gè) Maven 項(xiàng)目想要獲取一個(gè)jar包的話，他該從哪個(gè)倉庫中去獲取呢？下圖就是一個(gè)簡(jiǎn)單的描述：

首先 Maven 會(huì)到本地倉庫中去尋找所需要的jar吧，如果找不到就會(huì)到配置的私有倉庫中去找，如果私有倉庫中也找不到的話，就會(huì)到配置的中央倉庫中去找，如果還是找不到就會(huì)報(bào)錯(cuò)。但是這中間只要在某一個(gè)倉庫中找到了就會(huì)返回了，除非倉庫中有更新的版本，或者是snapshot版本。

那么 Maven 的遠(yuǎn)程倉庫是怎么配置的呢？假設(shè)我們要配置一個(gè)中央倉庫，可以像下面這樣配置：

最佳實(shí)踐

但是官方并不推薦直接配置遠(yuǎn)程倉庫，例如直接配置一個(gè)中央倉庫，而是通過 倉庫管理器 來下載我們所需要的jar包。試想一下如果你所在的公司有幾千甚至上萬的開發(fā)者，每個(gè)人都單獨(dú)配置一個(gè)中央倉庫，那每個(gè)人都到中央倉庫中去下載所需的jar，這就退化成最原始的模式，并且是一個(gè)巨大的資源浪費(fèi)。

那什么是 倉庫管理器 呢？倉庫管理器是一種專用服務(wù)器應(yīng)用程序，目的是用來管理二進(jìn)制組件的存儲(chǔ)庫。對(duì)于任何使用 Maven 的項(xiàng)目，倉庫管理器的使用被認(rèn)為是必不可少的最佳實(shí)踐。

倉庫管理器提供了以下基本用途：

充當(dāng)中央Maven存儲(chǔ)庫的專用代理服務(wù)器提供存儲(chǔ)庫作為Maven項(xiàng)目輸出的部署目標(biāo)

使用倉庫管理器可以獲得以下優(yōu)點(diǎn)和功能：

顯著減少了遠(yuǎn)程存儲(chǔ)庫的下載次數(shù)，節(jié)省了時(shí)間和帶寬，從而提高了構(gòu)建性能由于減少了對(duì)外部存儲(chǔ)庫的依賴，提高了構(gòu)建穩(wěn)定性與遠(yuǎn)程SNAPSHOT存儲(chǔ)庫交互的性能提高提供了一個(gè)有效的平臺(tái)，用于在組織內(nèi)外交換二進(jìn)制工件，而無需從源代碼中構(gòu)建工件。。。

已知的開源和商業(yè)存儲(chǔ)庫管理器有以下這些：

Apache Archiva（開源）CloudRepo（商業(yè)）Cloudsmith套餐（商業(yè)）JFrog Artifactory開源（開源）JFrog Artifactory Pro（商業(yè)）Sonatype Nexus OSS（開源）Sonatype Nexus Pro（商業(yè)）packagecloud.io（商業(yè)）

鏡像

Mirror 則相當(dāng)于一個(gè)代理，它會(huì)攔截去指定的遠(yuǎn)程 Repository 下載構(gòu)件的請(qǐng)求，然后從自己這里找出構(gòu)件回送給客戶端。配置 Mirror 的目的一般是出于網(wǎng)速考慮。

Repository 和 Mirror 是兩個(gè)不同的概念：前者本身是一個(gè)倉庫，可以堆外提供服務(wù)，而后者本身并不是一個(gè)倉庫，它只是遠(yuǎn)程倉庫的網(wǎng)絡(luò)加速器。

需要注意的是很多本地倉庫搭建工具往往也提供 Mirror 服務(wù)，比如Nexus就可以讓同一個(gè)URL,既用作 internalrepository，又使它成為所有 repository 的 Mirror。

如果 倉庫X 可以提供 倉庫Y 存儲(chǔ)的所有內(nèi)容，那么就可以認(rèn)為 X是Y的一個(gè)鏡像。這也意味著，任何一個(gè)可以從某個(gè)倉庫中獲得的構(gòu)件，都可以從它的鏡像中獲取。

舉個(gè)例子：http://maven.net.cn/content/groups/public/ 是中央倉庫 http://repo1.maven.org/maven2/ 在中國(guó)的鏡像，由于地理位置的因素，該鏡像往往能夠提供比中央倉庫更快的服務(wù)。

因此，可以在Maven中配置該鏡像來替代中央倉庫。在settings.xml中配置如下代碼：

\的值為central，表示該鏡像是中央倉庫的鏡像，任何對(duì)于中央倉庫的請(qǐng)求都會(huì)轉(zhuǎn)至該鏡像，如下圖所示：

對(duì)于鏡像的最佳實(shí)踐是結(jié)合私服。由于私服可以代理任何外部的公共倉庫(包括中央倉庫)，因此，對(duì)于組織內(nèi)部的Maven用戶來說，使用一個(gè)私服地址就等于使用了所有需要的外部倉庫，這可以將配置集中到私服，從而簡(jiǎn)化Maven本身的配置。在這種情況下，任何需要的構(gòu)件都可以從私服獲得，私服就是所有倉庫的鏡像。

例如可以這樣來配置一個(gè)代理所有倉庫的鏡像：

\的值為星號(hào)，表示該鏡像是所有Maven倉庫的鏡像，任何對(duì)于遠(yuǎn)程倉庫的請(qǐng)求都會(huì)被轉(zhuǎn)至：internal-repository-url 這個(gè)地址。

下面給出一張 Maven 官方的架構(gòu)圖：

生命周期

生命周期是由 一組 有 順序 的 階段 構(gòu)成的一個(gè)整體，這么說可能有點(diǎn)繞，那讓我們來關(guān)注他里面的幾個(gè)重要的點(diǎn)：

一組：指的是可能有多個(gè)順序：指的是按照順序執(zhí)行，執(zhí)行某一個(gè)階段的指令時(shí)會(huì)依次先執(zhí)行該階段之前的指令階段：指的是具體要執(zhí)行的內(nèi)容

例如 Maven 有三個(gè)內(nèi)置的構(gòu)建生命周期： default， clean 和 site。每個(gè)生命周期都由一系列的階段所構(gòu)成，比如 default 生命周期的一個(gè)簡(jiǎn)易階段如下，完整的生命周期請(qǐng)參考官方文檔：

上圖中的每一個(gè)節(jié)點(diǎn)都是一個(gè) 階段 ，階段的執(zhí)行是按順序的，一個(gè)階段執(zhí)行完成之后才會(huì)執(zhí)行下一個(gè)階段。比如我們執(zhí)行了一個(gè)如下的指令：

mvn install

他實(shí)際會(huì)執(zhí)行 install 階段之前的所有階段，然后才會(huì)執(zhí)行 install 階段本身。

PS：當(dāng)我們的項(xiàng)目是多模塊的，我們?cè)谧铐攲訄?zhí)行該指令時(shí)，Maven 會(huì)遍歷每一個(gè)子模塊，依次執(zhí)行所有的階段。

坐標(biāo)

說到 Maven 的坐標(biāo)，我們首先就需要想到 GAV ，即 groupId artifactId version。由這三個(gè)屬性就可以唯一確定一個(gè)jar包了。其中每個(gè)屬性的意義如下：

groupId：表示一個(gè)團(tuán)體，可以是公司、組織等artifactId：表示團(tuán)體下的某個(gè)項(xiàng)目version：表示某個(gè)項(xiàng)目的版本號(hào)

他們之間的關(guān)系是一對(duì)多的，即每個(gè)團(tuán)體下可以有多個(gè)項(xiàng)目，每個(gè)項(xiàng)目可以有多個(gè)版本號(hào)，可以用下面這張圖來表示：

依賴

Maven 核心特點(diǎn)之一是依賴管理。一旦我們開始處理多模塊工程(包含數(shù)百個(gè)子模塊或者子工程)的時(shí)候，模塊 間的依賴關(guān)系就變得非常復(fù)雜，管理也變得很困難。針對(duì)此種情形，Maven 提供了一種高度控制的方法。

依賴傳遞

依賴傳遞很好理解，假設(shè) B 依賴于 C，當(dāng) A 需要依賴 B 時(shí)，則 A 自動(dòng)獲得了對(duì) C 的依賴。依賴傳遞有時(shí)非常好，當(dāng)我們需要依賴很多jar包時(shí)，我們可以聲明一個(gè)包來依賴所有的jar，然后只要依賴這個(gè)包就可以了。但是有時(shí)又很麻煩，因?yàn)楹芸赡軙?huì)造成依賴的沖突。

依賴沖突

當(dāng)同一個(gè)項(xiàng)目中由于不同的jar包依賴了相同的jar包，此時(shí)就會(huì)發(fā)生依賴沖突的情況，如下圖所示：

當(dāng)項(xiàng)目中依賴了a和c，而a和c都依賴了b，這時(shí)就造成了沖突。為了避免沖突的產(chǎn)生，Maven 使用了兩種策略來解決沖突，分別是 短路優(yōu)先 和 聲明優(yōu)先 。

短路優(yōu)先

短路優(yōu)先的意識(shí)是，從項(xiàng)目一直到最終依賴的jar的距離，哪個(gè)距離短就依賴哪個(gè)，距離長(zhǎng)的將被忽略掉。例如下圖所示：

聲明優(yōu)先

聲明優(yōu)先的意思是，通過jar包聲明的順序來決定使用哪個(gè)，最先聲明的jar包總是被選中，后聲明的jar包則會(huì)被忽略，如下圖所示：

依賴排除

如果我們只想引用我們直接依賴的jar包，而不想把間接依賴的jar包也引入的話，那可以使用依賴排除的方式，將間接引用的jar包排除掉，如下面的配置所示：

解決沖突

項(xiàng)目中出現(xiàn)沖突，大體都是因?yàn)樯厦嫠枋龅脑颍缓?Maven 在選擇jar包時(shí)，選擇了一個(gè)錯(cuò)的包，導(dǎo)致出現(xiàn)問題，這時(shí)我們就需要人為來干預(yù)他，告訴 Maven 使用哪個(gè)正取的包。下面讓我舉個(gè)例子來說明沖突產(chǎn)生后該如何解決。

我們?cè)具\(yùn)行得好好的一個(gè)項(xiàng)目，突然有一次啟動(dòng)的時(shí)候，報(bào)錯(cuò)了，如下圖所示：

可以看到有報(bào)了一個(gè) NoSuchMethodError ，看到這個(gè)錯(cuò)，多半都是因?yàn)闆_突導(dǎo)致的。

錯(cuò)誤說的是找不到 javax.servlet.ServletContext 類中的 getVirtualServerName 方法了，那我們?cè)?idea 中搜索一下 javax.servlet.ServletContext 類，看看是否存在多個(gè)的情況，如下圖所示：

可以發(fā)現(xiàn)確實(shí)在兩個(gè)jar包中都找到了 javax.servlet.ServletContext 這個(gè)類，那我們打開他們看看哪個(gè)類沒有我們需要方法：

可以很清楚的看到，在 servlet-api-3.0.jar 包中沒有找到我們需要的方法，而 Maven 肯定是選擇了這個(gè)包。那就讓我們來看下依賴樹吧，看看 Maven 是怎樣選擇了錯(cuò)誤的包的。

在項(xiàng)目目錄中輸入如下指令：

mvn dependency:tree -Dverbose -Dincludes=javax.servlet：servlet-api

Maven 將打印出 servlet-api-3.0.jar 的包的依賴樹，如下圖所示：

然后在輸入如下指令：

mvn dependency:tree -Dverbose -Dincludes=javax.servlet:servlet-api

Maven 將打印出 tomcat-embed-core-8.5.31.jar 的包的依賴樹，如下圖所示：

我們分析下原因，從 Maven 中打印出的依賴樹來看，發(fā)現(xiàn)很奇怪的事：

servlet-api-3.0.jar 包是在 xx-service 模塊中引入的，從 xx-web 到他的深度為6，

tomcat-embed-core-8.5.31.jar 包是在 xx-web 模塊中引入的，從 xx-web 到他的深度為3。

那按照短路優(yōu)先的規(guī)則，Maven 應(yīng)該會(huì)選擇 tomcat-embed-core-8.5.31.jar 包才對(duì)，現(xiàn)在沒有選擇他，那原因肯定只有一個(gè)了：聲明優(yōu)先！

說明 servlet-api-3.0.jar 包比 tomcat-embed-core-8.5.31.jar 包先聲明。

我們發(fā)現(xiàn) servlet-api-3.0.jar 包是在 xx-service 中被引入的，

而 tomcat-embed-core-8.5.31.jar 是在 spring-boot-starter-web 中被引入的。

那只要能證明在 xx-web 中 xx-service 先于 spring-boot-starter-web 聲明就可以了，讓我們?nèi)?xx-web 中看看：

事實(shí)證明了我們的猜想是正確的， xx-service 確實(shí)比 spring-boot-starter-web 先聲明！

可以用圖形表示成如下：

那知道原因了，要解決這個(gè)沖突，就很好辦了，有兩種方法：

在 xx-web 中將 xx-service 放到 spring-boot-starter-web 后面聲明在 xx-service 中找到引入 servlet-api-3.0.jar 包將他排除掉

依賴管理

聚合

將多個(gè)項(xiàng)目同時(shí)運(yùn)行就稱為聚合，如下就是一個(gè)多模塊的項(xiàng)目：

聚合的優(yōu)勢(shì)在于可以在一個(gè)地方編譯多個(gè) pom 文件。

PS：聚合時(shí) packaging 必須要是 pom

繼承

跟java類的繼承類似，Maven 的繼承特性也會(huì)繼承父pom中的依賴，假設(shè)我們定義了一個(gè)父pom：

然后在子pom中引入這個(gè)父pom：

使用dependencyManagement，可對(duì)依賴進(jìn)行管理。子類只要不引用這個(gè)里面寫的groupId + artifactId，則不會(huì)添加依賴，這樣防止造成重復(fù)加了包：如果不使用dependencyManagement，那么只要寫了dependency，子pom中會(huì)全部添加到依賴中，而其中很多包可能都用不上。

插件

插件是 Maven 的核心，所有執(zhí)行的操作都是基于插件來完成的。

為了讓一個(gè)插件中可以實(shí)現(xiàn)眾多的相類似的功能，Maven 為插件設(shè)定了目標(biāo)，一個(gè)插件中有可能有多個(gè)目標(biāo)。其實(shí)生命周期中的每個(gè)階段都是由插件的一個(gè)具體目標(biāo)來執(zhí)行的

例如可以用下面的方式配置一個(gè)插件：

配置目標(biāo) goal 的目的是：這樣在執(zhí)行 mvnpackage 的時(shí)候，就會(huì)自動(dòng)執(zhí)行 mvn source:jar-no-fork了，jar-no-fork這個(gè)目標(biāo)是用來進(jìn)行源碼打包的。

除了可以在build元素中配置插件，當(dāng)然也可以在parent項(xiàng)目中，用pluginManagement來配置，然后在子項(xiàng)目繼承即可使用。

PS：通過插件我們可以做很多事，比如通過mybatis-generator 我們可以生成很多DAO層的代碼，再配合通用Mapper+lombok使用的話就可以使你的代碼非常簡(jiǎn)潔，絕對(duì)的生產(chǎn)力工具！

指令

下面列舉一些常用的 maven 指令：

指令參數(shù)

上面列舉的只是比較通用的命令，其實(shí)很多命令都可以攜帶參數(shù)以執(zhí)行更精準(zhǔn)的任務(wù)。 Maven命令可攜帶的參數(shù)類型如下：

-D 傳入屬性參數(shù)

比如命令： mvnpackage-Dmaven.test.skip=true以 -D開頭，將 maven.test.skip 的值設(shè)為 true ,就是告訴maven打包的時(shí)候跳過單元測(cè)試。

同理， mvn deploy-Dmaven.test.skip=true 代表部署項(xiàng)目并跳過單元測(cè)試。

-P 使用指定的Profile配置

比如項(xiàng)目開發(fā)需要有多個(gè)環(huán)境，一般為開發(fā)，測(cè)試，預(yù)發(fā)，正式4個(gè)環(huán)境，在pom.xml中的配置如下：

profiles定義了各個(gè)環(huán)境的變量 id， filters中定義了變量配置文件的地址，其中地址中的環(huán)境變量就是上面 profile中定義的值， resources中是定義哪些目錄下的文件會(huì)被配置文件中定義的變量替換。

通過maven可以實(shí)現(xiàn)按不同環(huán)境進(jìn)行打包部署，命令為:

mvn package -P dev

其中 dev 為環(huán)境的變量id,代表使用Id為 dev 的 profile。

-e 顯示maven運(yùn)行出錯(cuò)的信息

-o 離線執(zhí)行命令,即不去遠(yuǎn)程倉庫更新包

-X 顯示maven允許的debug信息

-U 強(qiáng)制去遠(yuǎn)程更新snapshot的插件或依賴，默認(rèn)每天只更新一次

舉個(gè)例子

將自己的jar包部署到遠(yuǎn)程倉庫去，可以使用 deploy 指令：

最后說下我們?yōu)槭裁匆獙W(xué)習(xí)maven，大概可以收獲這些好處吧：

提高自己的生產(chǎn)力更好的管理項(xiàng)目中的jar包自己開發(fā)的jar包可以共享給別人遇到j(luò)ar包沖突問題可以不求人。。。

原文地址：https://dwz.cn/ddPIxQUZ

作者：逅弈