Maven的一大功能是管理項(xiàng)目依賴。為了能自動(dòng)化地解析任何一個(gè)Java構(gòu)件，Maven就必須將它們唯一標(biāo)識(shí)，這就依賴管理的底層基礎(chǔ)——坐標(biāo)。將詳細(xì)分析Maven坐標(biāo)的作用，解釋其每一個(gè)元素；在此基礎(chǔ)上，再介紹如何配置Maven，以及相關(guān)的經(jīng)驗(yàn)和技巧，以幫助我們管理項(xiàng)目依賴。

1、何為Maven坐標(biāo)

關(guān)于坐標(biāo)（Coordinate），大家最熟悉的定義應(yīng)該來(lái)自于平面幾何。在一個(gè)平面坐標(biāo)系中，坐標(biāo)（x,y）表示該平面上與x軸距離為y，與y軸距離為x的一點(diǎn)，任何一個(gè)坐標(biāo)都能夠唯一標(biāo)識(shí)該平面中的一點(diǎn)。

在實(shí)際生活中，我們也可以將地址看成是一種坐標(biāo)。省、市、區(qū)、街道等一系列信息同樣可以唯一標(biāo)識(shí)城市中的任一居住地址和工作地址。郵局和快遞公司正是基于這樣一種坐標(biāo)進(jìn)行日常工作的。

對(duì)應(yīng)于平面中的點(diǎn)和城市中的地址，Maven的世界中擁有數(shù)量非常巨大的構(gòu)件，也就是平時(shí)用的一些jar、war等文件。在Maven為這些構(gòu)件引入坐標(biāo)概念之前，我們無(wú)法使用任何一種方式來(lái)唯一標(biāo)識(shí)所有這些構(gòu)件。因此，當(dāng)需要用到Spring Framework依賴的時(shí)候，大家會(huì)去Spring Framework網(wǎng)站尋找，當(dāng)需要用到log4j依賴的時(shí)候，大家又會(huì)去Apache網(wǎng)站尋找。又因?yàn)楦鱾€(gè)項(xiàng)目的網(wǎng)站風(fēng)格迥異，大量的時(shí)間花費(fèi)在了搜索、瀏覽網(wǎng)頁(yè)等工作上面。沒(méi)有統(tǒng)一的規(guī)范、統(tǒng)一的法則，該工作就無(wú)法自動(dòng)化。重復(fù)地搜索、瀏覽網(wǎng)頁(yè)和下載類(lèi)似的jar文件，這本就應(yīng)該交給機(jī)器來(lái)做。而機(jī)器工作必須基于預(yù)定義的規(guī)則，Maven定義了這樣一組規(guī)則：世界上任何一個(gè)構(gòu)件都可以使用Maven坐標(biāo)唯一標(biāo)識(shí)，Maven坐標(biāo)的元素包括groupId、artifactId、version、packaging、classifier?，F(xiàn)在，只要我們提供正確的坐標(biāo)元素，Maven就能找到對(duì)應(yīng)的構(gòu)件。比如說(shuō)，當(dāng)需要使用Java5平臺(tái)上TestNG的5.8版本時(shí)，就告訴Maven：“groupId=org.testng；artifactId=testng；version=5.8；classifier=jdk15”，Maven就會(huì)從倉(cāng)庫(kù)中尋找相應(yīng)的構(gòu)件供我們使用。也許你會(huì)奇怪，“Maven是從哪里下載構(gòu)件的呢？”答案其實(shí)很簡(jiǎn)單，Maven內(nèi)置了一個(gè)中央倉(cāng)庫(kù)的地址（http://repo1.maven.org/maven2），該中央倉(cāng)庫(kù)包含了世界上大部分流行的開(kāi)源項(xiàng)目構(gòu)件，Maven會(huì)在需要的時(shí)候去那里下載。

在我們開(kāi)發(fā)自己項(xiàng)目的時(shí)候，也需要為其定義適當(dāng)?shù)淖鴺?biāo)，這是Maven強(qiáng)制要求的。在這個(gè)基礎(chǔ)上，其他Maven項(xiàng)目才能引用該項(xiàng)目生成的構(gòu)件，見(jiàn)下圖：

2、坐標(biāo)詳解

Maven坐標(biāo)為各種構(gòu)件引入了秩序，任何一個(gè)構(gòu)件都必須明確定義自己的坐標(biāo)，而一組Maven坐標(biāo)是通過(guò)一些元素定義的，它們是groupId、artifactId、version、packaging、classifier。先看一組坐標(biāo)定義，如下：

＜groupId＞org.sonatype.nexus＜/groupId＞
＜artifactId＞nexus-indexer＜/artifactId＞
＜version＞2.0.0＜/version＞
＜packaging＞jar＜/packaging＞

這是nexus-indexer的坐標(biāo)定義，nexus-indexer是一個(gè)對(duì)Maven倉(cāng)庫(kù)編纂索引并提供搜索功能的類(lèi)庫(kù)，它是Nexus項(xiàng)目的一個(gè)子模塊。后面會(huì)詳細(xì)介紹Nexus。上述代碼片段中，其坐標(biāo)分別為groupId:org.sonatype.nexus、artifactId:nexus-indexer、version:2.0.0、packaging:jar，沒(méi)有classifier。下面詳細(xì)解釋一下各個(gè)坐標(biāo)元素：
這是nexus-indexer的坐標(biāo)定義，nexus-indexer是一個(gè)對(duì)Maven倉(cāng)庫(kù)編纂索引并提供搜索功能的類(lèi)庫(kù)，它是Nexus項(xiàng)目的一個(gè)子模塊。上述代碼片段中，其坐標(biāo)分別為groupId:org.sonatype.nexus、artifactId:nexus-indexer、version:2.0.0、packaging:jar，沒(méi)有classifier。下面詳細(xì)解釋一下各個(gè)坐標(biāo)元素：

• groupId：定義當(dāng)前Maven項(xiàng)目隸屬的實(shí)際項(xiàng)目。首先，Maven項(xiàng)目和實(shí)際項(xiàng)目不一定是一對(duì)一的關(guān)系。比如SpringFramework這一實(shí)際項(xiàng)目，其對(duì)應(yīng)的Maven項(xiàng)目會(huì)有很多，如spring-core、spring-context等。這是由于Maven中模塊的概念，因此，一個(gè)實(shí)際項(xiàng)目往往會(huì)被劃分成很多模塊。其次，groupId不應(yīng)該對(duì)應(yīng)項(xiàng)目隸屬的組織或公司。原因很簡(jiǎn)單，一個(gè)組織下會(huì)有很多實(shí)際項(xiàng)目，如果groupId只定義到組織級(jí)別，而后面我們會(huì)看到，artifactId只能定義Maven項(xiàng)目（模塊），那么實(shí)際項(xiàng)目這個(gè)層將難以定義。最后，groupId的表示方式與Java包名的表示方式類(lèi)似，通常與域名反向一一對(duì)應(yīng)。上例中，groupId為org.sonatype.nexus,org.sonatype表示Sonatype公司建立的一個(gè)非盈利性組織，nexus表示Nexus這一實(shí)際項(xiàng)目，該groupId與域名nexus.sonatype.org對(duì)應(yīng)。
• artifactId：該元素定義實(shí)際項(xiàng)目中的一個(gè)Maven項(xiàng)目（模塊），推薦的做法是使用實(shí)際項(xiàng)目名稱作為artifactId的前綴。比如上例中的artifactId是nexus-indexer，使用了實(shí)際項(xiàng)目名nexus作為前綴，這樣做的好處是方便尋找實(shí)際構(gòu)件。在默認(rèn)情況下，Maven生成的構(gòu)件，其文件名會(huì)以artifactId作為開(kāi)頭，如nexus-indexer-2.0.0.jar，使用實(shí)際項(xiàng)目名稱作為前綴之后，就能方便從一個(gè)lib文件夾中找到某個(gè)項(xiàng)目的一組構(gòu)件?？紤]有5個(gè)項(xiàng)目，每個(gè)項(xiàng)目都有一個(gè)core模塊，如果沒(méi)有前綴，我們會(huì)看到很多core-1.2.jar這樣的文件，加上實(shí)際項(xiàng)目名前綴之后，便能很容易區(qū)分foo-core-1.2.jar、bar-core-1.2.jar……
• version：該元素定義Maven項(xiàng)目當(dāng)前所處的版本，如上例中nexus-indexer的版本是2.0.0。需要注意的是，Maven定義了一套完整的版本規(guī)范，以及快照（SNAPSHOT）的概念。
• packaging：該元素定義Maven項(xiàng)目的打包方式。首先，打包方式通常與所生成構(gòu)件的文件擴(kuò)展名對(duì)應(yīng)，如上例中packaging為jar，最終的文件名為nexus-indexer-2.0.0.jar，而使用war打包方式的Maven項(xiàng)目，最終生成的構(gòu)件會(huì)有一個(gè).war文件，不過(guò)這不是絕對(duì)的。其次，打包方式會(huì)影響到構(gòu)建的生命周期，比如jar打包和war打包會(huì)使用不同的命令。最后，當(dāng)不定義packaging的時(shí)候，Maven會(huì)使用默認(rèn)值jar。
• classifier：該元素用來(lái)幫助定義構(gòu)建輸出的一些附屬構(gòu)件。附屬構(gòu)件與主構(gòu)件對(duì)應(yīng)，如上例中的主構(gòu)件是nexus-indexer-2.0.0.jar，該項(xiàng)目可能還會(huì)通過(guò)使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar這樣一些附屬構(gòu)件，其包含了Java文檔和源代碼。這時(shí)候，javadoc和sources就是這兩個(gè)附屬構(gòu)件的classifier。這樣，附屬構(gòu)件也就擁有了自己唯一的坐標(biāo)。還有一個(gè)關(guān)于classifier的典型例子是TestNG,TestNG的主構(gòu)件是基于Java 1.4平臺(tái)的，而它又提供了一個(gè)classifier為jdk5的附屬構(gòu)件。注意，不能直接定義項(xiàng)目的classifier，因?yàn)楦綄贅?gòu)件不是項(xiàng)目直接默認(rèn)生成的，而是由附加的插件幫助生成。

上述5個(gè)元素中，groupId、artifactId、version是必須定義的，packaging是可選的（默認(rèn)為jar），而classifier是不能直接定義的。

同時(shí)，項(xiàng)目構(gòu)件的文件名是與坐標(biāo)相對(duì)應(yīng)的，一般的規(guī)則為artifactId-version[-classifier].packaging，[-classifier]表示可選。比如上例nexus-indexer的主構(gòu)件為nexus-indexer-2.0.0.jar，附屬構(gòu)件有nexus-indexer-2.0.0-javadoc.jar。這里還要強(qiáng)調(diào)的一點(diǎn)是，packaging并非一定與構(gòu)件擴(kuò)展名對(duì)應(yīng)，比如packaging為maven-plugin的構(gòu)件擴(kuò)展名為jar。此外，Maven倉(cāng)庫(kù)的布局也是基于Maven坐標(biāo)。

理解清楚城市中地址的定義方式后，郵遞員就能夠開(kāi)始工作了；同樣地，理解清楚Maven坐標(biāo)之后，我們就能開(kāi)始討論Maven的依賴管理了。

3、解析一個(gè)Maven項(xiàng)目的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.0
http://maven.apache.org/maven-v4_0_0.xsd"＞
＜modelVersion＞4.0.0＜/modelVersion＞
＜groupId＞com.juvenxu.mvnbook.account＜/groupId＞
＜artifactId＞account-email＜/artifactId＞
＜name＞Account Email＜/name＞
＜version＞1.0.0-SNAPSHOT＜/version＞
＜dependencies＞
＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-core＜/artifactId＞
＜version＞2.5.6＜/version＞
＜/dependency＞
＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-beans＜/artifactId＞
＜version＞2.5.6＜/version＞
＜/dependency＞
＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-context＜/artifactId＞
＜version＞2.5.6＜/version＞
＜/dependency＞
＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-context-support＜/artifactId＞
＜version＞2.5.6＜/version＞
＜/dependency＞
＜dependency＞
＜groupId＞javax.mail＜/groupId＞
＜artifactId＞mail＜/artifactId＞
＜version＞1.4.1＜/version＞
＜/dependency＞
＜dependency＞
＜groupId＞junit＜/groupId＞
＜artifactId＞junit＜/artifactId＞
＜version＞4.7＜/version＞
＜scope＞test＜/scope＞
＜/dependency＞
＜dependency＞
＜groupId＞com.icegreen＜/groupId＞
＜artifactId＞greenmail＜/artifactId＞
＜version＞1.3.1b＜/version＞
＜scope＞test＜/scope＞
＜/dependency＞
＜/dependencies＞
＜build＞
＜plugins＞
＜plugin＞
＜groupId＞org.apache.maven.plugins＜/groupId＞
＜artifactId＞maven-compiler-plugin＜/artifactId＞
＜configuration＞
＜source＞1.5＜/source＞
＜target＞1.5＜/target＞
＜/configuration＞
＜/plugin＞
＜/plugins＞
＜/build＞
＜/project＞

先觀察該項(xiàng)目模塊的坐標(biāo)，groupId:com.juvenxu.mvnbook.account；artifactId:account-email；version:1.0.0-SNAPSHOT。由于該模塊屬于賬戶注冊(cè)服務(wù)項(xiàng)目的一部分，因此，其groupId對(duì)應(yīng)了account項(xiàng)目。緊接著，該模塊的artifactId仍然以account作為前綴，以方便區(qū)分其他項(xiàng)目的構(gòu)建。最后，1.0.0-SNAPSHOT表示該版本處于開(kāi)發(fā)中，還不穩(wěn)定。

再看dependencies元素，其包含了多個(gè)dependency子元素，這是POM中定義項(xiàng)目依賴的位置。以第一個(gè)依賴為例，其groupId:artifactId:version為org.springframework:spring-core:2.5.6，這便是依賴的坐標(biāo)，任何一個(gè)Maven項(xiàng)目都需要定義自己的坐標(biāo)，當(dāng)這個(gè)Maven項(xiàng)目成為其他Maven項(xiàng)目的依賴的時(shí)候，這組坐標(biāo)就體現(xiàn)了其價(jià)值。本例中的spring-core，以及后面的spring-beans、spring-context、spring-context-support是Spring Framework實(shí)現(xiàn)依賴注入等功能必要的構(gòu)件，由于我們的關(guān)注點(diǎn)在于Maven，只會(huì)涉及簡(jiǎn)單的Spring Framework的使用，不會(huì)詳細(xì)解釋Spring Framework的用法，如果大家有不清楚的地方，請(qǐng)參閱Spring Framework相關(guān)的文檔。

在spring-context-support之后，有一個(gè)依賴為javax.mail:mail:1.4.1，這是實(shí)現(xiàn)發(fā)送必須的類(lèi)庫(kù)。

緊接著的依賴為junit:junit:4.7，JUnit是Java社區(qū)事實(shí)上的單元測(cè)試標(biāo)準(zhǔn)，詳細(xì)信息請(qǐng)參閱http://www.junit.org/，這個(gè)依賴特殊的地方在于一個(gè)值為test的scope子元素，scope用來(lái)定義依賴范圍。這里我們暫時(shí)只需要了解當(dāng)依賴范圍是test的時(shí)候，該依賴只會(huì)被加入到測(cè)試代碼的classpath中。也就是說(shuō)，對(duì)于項(xiàng)目主代碼，該依賴是沒(méi)有任何作用的。JUnit是單元測(cè)試框架，只有在測(cè)試的時(shí)候才需要，因此使用該依賴范圍。

隨后的依賴是com.icegreen:greenmail:1.3.1b，其依賴范圍同樣為test。這時(shí)也許你已經(jīng)猜到，該依賴同樣只服務(wù)于測(cè)試目的，GreenMail是開(kāi)源的郵件服務(wù)測(cè)試套件，account-email模塊使用該套件來(lái)測(cè)試郵件的發(fā)送。關(guān)于GreenMail的詳細(xì)信息可訪問(wèn)http://www.icegreen.com/greenmail/。

最后，POM中有一段關(guān)于maven-compiler-plugin的配置，其目的是開(kāi)啟Java 5的支持。

3.1、構(gòu)建項(xiàng)目

使用mvn clean install構(gòu)建account-email,Maven會(huì)根據(jù)POM配置自動(dòng)下載所需要的依賴構(gòu)件，執(zhí)行編譯、測(cè)試、打包等工作，最后將項(xiàng)目生成的構(gòu)件account-email-1.0.0-SNAP-SHOT.jar安裝到本地倉(cāng)庫(kù)中。這時(shí)，該模塊就能供其他Maven項(xiàng)目使用了。

4、依賴的配置

依賴會(huì)有基本的groupId、arti-factId和version等元素組成。其實(shí)一個(gè)依賴聲明可以包含如下的一些元素：

＜project＞
……
＜dependencies＞
＜dependency＞
＜groupId＞……＜/groupId＞
＜artifactId＞……＜/artifactId＞
＜version＞……＜/version＞
＜type＞……＜/type＞
＜scope＞……＜/scope＞
＜o(jì)ptional＞……＜/optional＞
＜exclusions＞
＜exclusion＞……＜/exclusion＞
……
＜/exclusions＞
＜/dependency＞
……
＜/dependencies＞
……
＜/project＞

根元素project下的dependencies可以包含一個(gè)或者多個(gè)dependency元素，以聲明一個(gè)或者多個(gè)項(xiàng)目依賴。每個(gè)依賴可以包含的元素有：

• groupId、artifactId和version：依賴的基本坐標(biāo)，對(duì)于任何一個(gè)依賴來(lái)說(shuō)，基本坐標(biāo)是最重要的，Maven根據(jù)坐標(biāo)才能找到需要的依賴。
• type：依賴的類(lèi)型，對(duì)應(yīng)于項(xiàng)目坐標(biāo)定義的packaging。大部分情況下，該元素不必聲明，其默認(rèn)值為jar。
• scope：依賴的范圍。
• optional：標(biāo)記依賴是否可選。
• exclusions：用來(lái)排除傳遞性依賴。

大部分依賴聲明只包含基本坐標(biāo)，然而在一些特殊情況下，其他元素至關(guān)重要。

5、依賴范圍

上一節(jié)提到，JUnit依賴的測(cè)試范圍是test，測(cè)試范圍用元素scope表示。本節(jié)將詳細(xì)解釋什么是測(cè)試范圍，以及各種測(cè)試范圍的效果和用途。

首先需要知道，Maven在編譯項(xiàng)目主代碼的時(shí)候需要使用一套classpath。在上例中，編譯項(xiàng)目主代碼的時(shí)候需要用到spring-core，該文件以依賴的方式被引入到classpath中。其次，Maven在編譯和執(zhí)行測(cè)試的時(shí)候會(huì)使用另外一套classpath。上例中的JUnit就是一個(gè)很好的例子，該文件也以依賴的方式引入到測(cè)試使用的classpath中，不同的是這里的依賴范圍是test。最后，實(shí)際運(yùn)行Maven項(xiàng)目的時(shí)候，又會(huì)使用一套classpath，上例中的spring-core需要在該classpath中，而JUnit則不需要。

依賴范圍就是用來(lái)控制依賴與這三種classpath（編譯classpath、測(cè)試classpath、運(yùn)行classpath）的關(guān)系，Maven有以下幾種依賴范圍：

• compile：編譯依賴范圍。如果沒(méi)有指定，就會(huì)默認(rèn)使用該依賴范圍。使用此依賴范圍的Maven依賴，對(duì)于編譯、測(cè)試、運(yùn)行三種classpath都有效。典型的例子是spring-core，在編譯、測(cè)試和運(yùn)行的時(shí)候都需要使用該依賴。
• test：測(cè)試依賴范圍。使用此依賴范圍的Maven依賴，只對(duì)于測(cè)試classpath有效，在編譯主代碼或者運(yùn)行項(xiàng)目的使用時(shí)將無(wú)法使用此類(lèi)依賴。典型的例子是JUnit，它只有在編譯測(cè)試代碼及運(yùn)行測(cè)試的時(shí)候才需要。
• test：測(cè)試依賴范圍。使用此依賴范圍的Maven依賴，只對(duì)于測(cè)試classpath有效，在編譯主代碼或者運(yùn)行項(xiàng)目的使用時(shí)將無(wú)法使用此類(lèi)依賴。典型的例子是JUnit，它只有在編譯測(cè)試代碼及運(yùn)行測(cè)試的時(shí)候才需要。
• provided：已提供依賴范圍。使用此依賴范圍的Maven依賴，對(duì)于編譯和測(cè)試class-path有效，但在運(yùn)行時(shí)無(wú)效。典型的例子是servlet-api，編譯和測(cè)試項(xiàng)目的時(shí)候需要該依賴，但在運(yùn)行項(xiàng)目的時(shí)候，由于容器已經(jīng)提供，就不需要Maven重復(fù)地引入一遍。
• runtime：運(yùn)行時(shí)依賴范圍。使用此依賴范圍的Maven依賴，對(duì)于測(cè)試和運(yùn)行class-path有效，但在編譯主代碼時(shí)無(wú)效。典型的例子是JDBC驅(qū)動(dòng)實(shí)現(xiàn)，項(xiàng)目主代碼的編譯只需要JDK提供的JDBC接口，只有在執(zhí)行測(cè)試或者運(yùn)行項(xiàng)目的時(shí)候才需要實(shí)現(xiàn)上述接口的具體JDBC驅(qū)動(dòng)。
• system：系統(tǒng)依賴范圍。該依賴與三種classpath的關(guān)系，和provided依賴范圍完全一致。但是，使用system范圍的依賴時(shí)必須通過(guò)systemPath元素顯式地指定依賴文件的路徑。由于此類(lèi)依賴不是通過(guò)Maven倉(cāng)庫(kù)解析的，而且往往與本機(jī)系統(tǒng)綁定，可能造成構(gòu)建的不可移植，因此應(yīng)該謹(jǐn)慎使用。systemPath元素可以引用環(huán)境變量，如：

＜dependency＞
＜groupId＞javax.sql＜/groupId＞
＜artifactId＞jdbc-stdext＜/artifactId＞
＜version＞2.0＜/version＞
＜scope＞system＜/scope＞
＜systemPath＞${java.home}/lib/rt.jar＜/systemPath＞
＜/dependency＞

• import（Maven 2.0.9及以上）：導(dǎo)入依賴范圍。該依賴范圍不會(huì)對(duì)三種classpath產(chǎn)生實(shí)際的影響，后面將介紹Maven依賴和dependencyManagement的時(shí)候詳細(xì)介紹此依賴范圍。

上述除import以外的各種依賴范圍與三種classpath的關(guān)系如下表所示：

6、傳遞性依賴

6.1、何為傳遞性依賴

考慮一個(gè)基于Spring Framework的項(xiàng)目，如果不使用Maven，那么在項(xiàng)目中就需要手動(dòng)下載相關(guān)依賴。由于Spring Framework又會(huì)依賴于其他開(kāi)源類(lèi)庫(kù)，因此實(shí)際中往往會(huì)下載一個(gè)很大的如spring-framework-2.5.6-with-dependencies.zip的包，這里包含了所有Spring Framework的jar包，以及所有它依賴的其他jar包。這么做往往就引入了很多不必要的依賴。另一種做法是只下載spring-framework-2.5.6.zip這樣一個(gè)包，這里不包含其他相關(guān)依賴，到實(shí)際使用的時(shí)候，再根據(jù)出錯(cuò)信息，或者查詢相關(guān)文檔，加入需要的其他依賴。很顯然，這也是一件非常麻煩的事情。

Maven的傳遞性依賴機(jī)制可以很好地解決這一問(wèn)題。以account-email項(xiàng)目為例，該項(xiàng)目有一個(gè)org.springframework:spring-core:2.5.6的依賴，而實(shí)際上spring-core也有它自己的依賴，我們可以直接訪問(wèn)位于中央倉(cāng)庫(kù)的該構(gòu)件的POM:http://repo1.maven.org/maven2/org/springframework/spring-core/2.5.6/spring-core-2.5.6.pom。該文件包含了一個(gè)commons-logging依賴，代碼清單如下所示：

＜dependency＞
＜groupId＞commons-logging＜/groupId＞
＜artifactId＞commons-logging＜/artifactId＞
＜version＞1.1.1＜/version＞
＜/dependency＞

該依賴沒(méi)有聲明依賴范圍，那么其依賴范圍就是默認(rèn)的compile。同時(shí)回顧一下account-email,spring-core的依賴范圍也是compile。

account-mail有一個(gè)compile范圍的spring-core依賴，spring-core有一個(gè)compile范圍的commons-logging依賴，那么commons-logging就會(huì)成為account-email的compile范圍依賴，commons-logging是account-email的一個(gè)傳遞性依賴，如下圖所示：

有了傳遞性依賴機(jī)制，在使用Spring Framework的時(shí)候就不用去考慮它依賴了什么，也不用擔(dān)心引入多余的依賴。Maven會(huì)解析各個(gè)直接依賴的POM，將那些必要的間接依賴，以傳遞性依賴的形式引入到當(dāng)前的項(xiàng)目中。

6.2、傳遞性依賴和依賴范圍

依賴范圍不僅可以控制依賴與三種classpath的關(guān)系，還對(duì)傳遞性依賴產(chǎn)生影響。上面的例子中，account-email對(duì)于spring-core的依賴范圍是compile,spring-core對(duì)于commons-logging的依賴范圍是compile，那么account-email對(duì)于commons-logging這一傳遞性依賴的范圍也就是compile。假設(shè)A依賴于B,B依賴于C，我們說(shuō)A對(duì)于B是第一直接依賴，B對(duì)于C是第二直接依賴，A對(duì)于C是傳遞性依賴。第一直接依賴的范圍和第二直接依賴的范圍決定了傳遞性依賴的范圍，如下表所示，最左邊一列表示第一直接依賴范圍，最上面一行表示第二直接依賴范圍，中間的交叉單元格則表示傳遞性依賴范圍：

為了能夠幫助讀者更好地理解上表，這里再舉個(gè)例子。account-email項(xiàng)目有一個(gè)com.icegreen:greenmail:1.3.1b的直接依賴，我們說(shuō)這是第一直接依賴，其依賴范圍是test；而greenmail又有一個(gè)javax.mail:mail:1.4的直接依賴，我們說(shuō)這是第二直接依賴，其依賴范圍是compile。顯然javax.mail:mail:1.4是account-email的傳遞性依賴，對(duì)照上表可以知道，當(dāng)?shù)谝恢苯右蕾嚪秶鸀閠est，第二直接依賴范圍是compile的時(shí)候，傳遞性依賴的范圍是test，因此javax.mail:mail:1.4是account-email的一個(gè)范圍是test的傳遞性依賴。

仔細(xì)觀察一下上表，可以發(fā)現(xiàn)這樣的規(guī)律：當(dāng)?shù)诙苯右蕾嚨姆秶莄ompile的時(shí)候，傳遞性依賴的范圍與第一直接依賴的范圍一致；當(dāng)?shù)诙苯右蕾嚨姆秶莟est的時(shí)候，依賴不會(huì)得以傳遞；當(dāng)?shù)诙苯右蕾嚨姆秶莗rovided的時(shí)候，只傳遞第一直接依賴范圍也為provided的依賴，且傳遞性依賴的范圍同樣為provided；當(dāng)?shù)诙苯右蕾嚨姆秶莚untime的時(shí)候，傳遞性依賴的范圍與第一直接依賴的范圍一致，但compile例外，此時(shí)傳遞性依賴的范圍為runtime。

7、依賴調(diào)解

Maven引入的傳遞性依賴機(jī)制，一方面大大簡(jiǎn)化和方便了依賴聲明，另一方面，大部分情況下我們只需要關(guān)心項(xiàng)目的直接依賴是什么，而不用考慮這些直接依賴會(huì)引入什么傳遞性依賴。但有時(shí)候，當(dāng)傳遞性依賴造成問(wèn)題的時(shí)候，我們就需要清楚地知道該傳遞性依賴是從哪條依賴路徑引入的。

Maven引入的傳遞性依賴機(jī)制，一方面大大簡(jiǎn)化和方便了依賴聲明，另一方面，大部分情況下我們只需要關(guān)心項(xiàng)目的直接依賴是什么，而不用考慮這些直接依賴會(huì)引入什么傳遞性依賴。但有時(shí)候，當(dāng)傳遞性依賴造成問(wèn)題的時(shí)候，我們就需要清楚地知道該傳遞性依賴是從哪條依賴路徑引入的。

依賴調(diào)解第一原則不能解決所有問(wèn)題，比如這樣的依賴關(guān)系：A-＞B-＞Y（1.0）、A-＞C-＞Y（2.0），Y（1.0）和Y（2.0）的依賴路徑長(zhǎng)度是一樣的，都為2。那么到底誰(shuí)會(huì)被解析使用呢？在Maven 2.0.8及之前的版本中，這是不確定的，但是從Maven 2.0.9開(kāi)始，為了盡可能避免構(gòu)建的不確定性，Maven定義了依賴調(diào)解的第二原則：第一聲明者優(yōu)先。在依賴路徑長(zhǎng)度相等的前提下，在POM中依賴聲明的順序決定了誰(shuí)會(huì)被解析使用，順序最靠前的那個(gè)依賴優(yōu)勝。該例中，如果B的依賴聲明在C之前，那么Y（1.0）就會(huì)被解析使用。

8、可選依賴

假設(shè)有這樣一個(gè)依賴關(guān)系，項(xiàng)目A依賴于項(xiàng)目B，項(xiàng)目B依賴于項(xiàng)目X和Y,B對(duì)于X和Y的依賴都是可選依賴：A-＞B、B-＞X（可選）、B-＞Y（可選）。根據(jù)傳遞性依賴的定義，如果所有這三個(gè)依賴的范圍都是compile，那么X、Y就是A的compile范圍傳遞性依賴。然而，由于這里X、Y是可選依賴，依賴將不會(huì)得以傳遞。換句話說(shuō)，X、Y將不會(huì)對(duì)A有任何影響，如下圖所示：

為什么要使用可選依賴這一特性呢？可能項(xiàng)目B實(shí)現(xiàn)了兩個(gè)特性，其中的特性一依賴于X，特性二依賴于Y，而且這兩個(gè)特性是互斥的，用戶不可能同時(shí)使用兩個(gè)特性。比如B是一個(gè)持久層隔離工具包，它支持多種數(shù)據(jù)庫(kù)，包括MySQL、PostgreSQL等，在構(gòu)建這個(gè)工具包的時(shí)候，需要這兩種數(shù)據(jù)庫(kù)的驅(qū)動(dòng)程序，但在使用這個(gè)工具包的時(shí)候，只會(huì)依賴一種數(shù)據(jù)庫(kù)。

項(xiàng)目B的依賴聲明見(jiàn)代碼如下所示：

＜project＞
＜modelVersion＞4.0.0＜/modelVersion＞
＜groupId＞com.juvenxu.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＞
＜o(jì)ptional＞true＜/optional＞
＜/dependency＞
＜dependency＞
＜groupId＞postgresql＜/groupId＞
＜artifactId＞postgresql＜/artifactId＞
＜version＞8.4-701.jdbc3＜/version＞
＜o(jì)ptional＞true＜/optional＞
＜/dependency＞
＜/dependencies＞
＜/project＞

上述XML代碼片段中，使用＜o(jì)ptional＞元素表示mysql-connector-java和postgresql這兩個(gè)依賴為可選依賴，它們只會(huì)對(duì)當(dāng)前項(xiàng)目B產(chǎn)生影響，當(dāng)其他項(xiàng)目依賴于B的時(shí)候，這兩個(gè)依賴不會(huì)被傳遞。因此，當(dāng)項(xiàng)目A依賴于項(xiàng)目B的時(shí)候，如果其實(shí)際使用基于MySQL數(shù)據(jù)庫(kù)，那么在項(xiàng)目A中就需要顯式地聲明mysql-connector-java這一依賴，見(jiàn)代碼如下所示：

＜project＞
＜modelVersion＞4.0.0＜/modelVersion＞
＜groupId＞com.juvenxu.mvnbook＜/groupId＞
＜artifactId＞project-a＜/artifactId＞
＜version＞1.0.0＜/version＞
＜dependencies＞
＜dependency＞
＜groupId＞com.juvenxu.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＞

最后，關(guān)于可選依賴需要說(shuō)明的一點(diǎn)是，在理想的情況下，是不應(yīng)該使用可選依賴的。前面我們可以看到，使用可選依賴的原因是某一個(gè)項(xiàng)目實(shí)現(xiàn)了多個(gè)特性，在面向?qū)ο笤O(shè)計(jì)中，有個(gè)單一職責(zé)性原則，意指一個(gè)類(lèi)應(yīng)該只有一項(xiàng)職責(zé)，而不是糅合太多的功能。這個(gè)原則在規(guī)劃Maven項(xiàng)目的時(shí)候也同樣適用。在上面的例子中，更好的做法是為MySQL和PostgreSQL分別創(chuàng)建一個(gè)Maven項(xiàng)目，基于同樣的groupId分配不同的artifactId，如com.juvenxu.mvnbook:project-b-mysql和com.juvenxu.mvnbook:project-b-postgresql，在各自的POM中聲明對(duì)應(yīng)的JDBC驅(qū)動(dòng)依賴，而且不使用可選依賴，用戶則根據(jù)需要選擇使用project-b-mysql或者project-b-postgresql。由于傳遞性依賴的作用，就不用再聲明JDBC驅(qū)動(dòng)依賴。

9、最佳實(shí)踐

Maven依賴涉及的知識(shí)點(diǎn)比較多，在理解了主要的功能和原理之后，最需要的當(dāng)然就是前人的經(jīng)驗(yàn)總結(jié)了，我們稱之為最佳實(shí)踐。本小節(jié)歸納了一些使用Maven依賴常見(jiàn)的技巧，方便用來(lái)避免和處理很多常見(jiàn)的問(wèn)題。

9.1、排除依賴

傳遞性依賴會(huì)給項(xiàng)目隱式地引入很多依賴，這極大地簡(jiǎn)化了項(xiàng)目依賴的管理，但是有些時(shí)候這種特性也會(huì)帶來(lái)問(wèn)題。例如，當(dāng)前項(xiàng)目有一個(gè)第三方依賴，而這個(gè)第三方依賴由于某些原因依賴了另外一個(gè)類(lèi)庫(kù)的SNAPSHOT版本，那么這個(gè)SNAPSHOT就會(huì)成為當(dāng)前項(xiàng)目的傳遞性依賴，而SNAPSHOT的不穩(wěn)定性會(huì)直接影響到當(dāng)前的項(xiàng)目。這時(shí)就需要排除掉該SNAPSHOT，并且在當(dāng)前項(xiàng)目中聲明該類(lèi)庫(kù)的某個(gè)正式發(fā)布的版本。還有一些情況，你可能也想要替換某個(gè)傳遞性依賴，比如Sun JTA API,Hibernate依賴于這個(gè)JAR，但是由于版權(quán)的因素，該類(lèi)庫(kù)不在中央倉(cāng)庫(kù)中，而Apache Geronimo項(xiàng)目有一個(gè)對(duì)應(yīng)的實(shí)現(xiàn)。這時(shí)你就可以排除Sun JAT API，再聲明Geronimo的JTA API實(shí)現(xiàn)，見(jiàn)代碼如下所示：

＜project＞
＜modelVersion＞4.0.0＜/modelVersion＞
＜groupId＞com.juvenxu.mvnbook＜/groupId＞
＜artifactId＞project-a＜/artifactId＞
＜version＞1.0.0＜/version＞
＜dependencies＞＜dependency＞
＜groupId＞com.juvenxu.mvnbook＜/groupId＞
＜artifactId＞project-b＜/artifactId＞
＜version＞1.0.0＜/version＞

＜exclusions＞
＜exclusion＞
＜groupId＞com.juvenxu.mvnbook＜/groupId＞
＜artifactId＞project-c＜/artifactId＞
＜/exclusion＞
＜/exclusions＞

＜/dependency＞
＜dependency＞
＜groupId＞com.juvenxu.mvnbook＜/groupId＞
＜artifactId＞project-c＜/artifactId＞
＜version＞1.1.0＜/version＞
＜/dependency＞

上述代碼中，項(xiàng)目A依賴于項(xiàng)目B，但是由于一些原因，不想引入傳遞性依賴C，而是自己顯式地聲明對(duì)于項(xiàng)目C 1.1.0版本的依賴。代碼中使用exclusions元素聲明排除依賴，exclusions可以包含一個(gè)或者多個(gè)exclusion子元素，因此可以排除一個(gè)或者多個(gè)傳遞性依賴。需要注意的是，聲明exclusion的時(shí)候只需要groupId和artifactId，而不需要version元素，這是因?yàn)橹恍枰猤roupId和artifactId就能唯一定位依賴圖中的某個(gè)依賴。換句話說(shuō)，Maven解析后的依賴中，不可能出現(xiàn)groupId和artifactId相同，但是version不同的兩個(gè)依賴。該例的依賴解析邏輯如下圖所示：

9.2、歸類(lèi)依賴

，有很多關(guān)于Spring Framework的依賴，它們分別是org.springframework:spring-core:2.5.6、org.springframework:spring-beans:2.5.6、org.springframework:spring-context:2.5.6和org.springframework:spring-context-support:2.5.6，它們是來(lái)自同一項(xiàng)目的不同模塊。因此，所有這些依賴的版本都是相同的，而且可以預(yù)見(jiàn)，如果將來(lái)需要升級(jí)Spring Frame-work，這些依賴的版本會(huì)一起升級(jí)。

對(duì)于account-email中這些Spring Framework來(lái)說(shuō)，也應(yīng)該在一個(gè)唯一的地方定義版本，并且在dependency聲明中引用這一版本。這樣，在升級(jí)Spring Framework的時(shí)候就只需要修改一處，實(shí)現(xiàn)方式見(jiàn)代碼清單如下：

＜project＞
＜modelVersion＞4.0.0＜/modelVersion＞
＜groupId＞com.juven.mvnbook.account＜/groupId＞
＜artifactId＞account-email＜/artifactId＞
＜name＞Account Email＜/name＞
＜version＞1.0.0-SNAPSHOT＜/version＞
＜properties＞
＜springframework.version＞2.5.6＜/springframework.version＞
＜/properties＞
＜dependencies＞
＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-core＜/artifactId＞
＜version＞${springframework.version}＜/version＞
＜/dependency＞

＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-beans＜/artifactId＞
＜version＞${springframework.version}＜/version＞
＜/dependency＞

＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-context＜/artifactId＞
＜version＞${springframework.version}＜/version＞
＜/dependency＞

＜dependency＞
＜groupId＞org.springframework＜/groupId＞
＜artifactId＞spring-context-support＜/artifactId＞
＜version＞${springframework.version}＜/version＞
＜/dependency＞

＜/dependencies＞
＜/project＞

這里簡(jiǎn)單用到了Maven屬性，首先使用properties元素定義Maven屬性，該例中定義了一個(gè)springframework.version子元素，其值為2.5.6。有了這個(gè)屬性定義之后，Maven運(yùn)行的時(shí)候會(huì)將POM中的所有的${springframework.version}替換成實(shí)際值2.5.6。也就是說(shuō)，可以使用美元符號(hào)和大括弧環(huán)繞的方式引用Maven屬性。然后，將所有Spring Framework依賴的版本值用這一屬性引用表示。

9.3、優(yōu)化依賴

在軟件開(kāi)發(fā)過(guò)程中，程序員會(huì)通過(guò)重構(gòu)等方式不斷地優(yōu)化自己的代碼，使其變得更簡(jiǎn)潔、更靈活。同理，程序員也應(yīng)該能夠?qū)aven項(xiàng)目的依賴了然于胸，并對(duì)其進(jìn)行優(yōu)化，如去除多余的依賴，顯式地聲明某些必要的依賴。

通過(guò)閱讀前面的內(nèi)容，我們應(yīng)該能夠了解到：Maven會(huì)自動(dòng)解析所有項(xiàng)目的直接依賴和傳遞性依賴，并且根據(jù)規(guī)則正確判斷每個(gè)依賴的范圍，對(duì)于一些依賴沖突，也能進(jìn)行調(diào)節(jié)，以確保任何一個(gè)構(gòu)件只有唯一的版本在依賴中存在。在這些工作之后，最后得到的那些依賴被稱為已解析依賴（Resolved Dependency）?？梢赃\(yùn)行如下的命令查看當(dāng)前項(xiàng)目的已解析依賴：

mvn dependency:list

上圖顯示了所有shardingsphere-5.3.0的已解析依賴，同時(shí)，每個(gè)依賴的范圍也得以明確標(biāo)示。

在此基礎(chǔ)上，還能進(jìn)一步了解已解析依賴的信息。將直接在當(dāng)前項(xiàng)目POM聲明的依賴定義為頂層依賴，而這些頂層依賴的依賴則定義為第二層依賴，以此類(lèi)推，有第三、第四層依賴。當(dāng)這些依賴經(jīng)Maven解析后，就會(huì)構(gòu)成一個(gè)依賴樹(shù)，通過(guò)這棵依賴樹(shù)就能很清楚地看到某個(gè)依賴是通過(guò)哪條傳遞路徑引入的?？梢赃\(yùn)行如下命令查看當(dāng)前項(xiàng)目的依賴樹(shù)：

mvn dependency:tree

從上圖中能夠看到，雖然我們沒(méi)有聲明org.slf4j:slf4japi:1.3這一依賴，但它還是經(jīng)過(guò)com.icegreen:greenmail:1.3成為了當(dāng)前項(xiàng)目的傳遞性依賴，而且其范圍是test。

使用dependency:list和dependency:tree可以幫助我們?cè)敿?xì)了解項(xiàng)目中所有依賴的具體信息，在此基礎(chǔ)上，還有dependency:analyze工具可以幫助分析當(dāng)前項(xiàng)目的依賴。

為了說(shuō)明該工具的用途，先將spring-context這一依賴刪除，然后構(gòu)建項(xiàng)目，你會(huì)發(fā)現(xiàn)編譯、測(cè)試和打包都不會(huì)有任何問(wèn)題。通過(guò)分析依賴樹(shù)，可以看到spring-context是spring-context-support的依賴，因此會(huì)得以傳遞到項(xiàng)目的classspath中?，F(xiàn)在再運(yùn)行如下命令：

mvn dependency:analyze

該結(jié)果中重要的是兩個(gè)部分。首先是Used undeclared dependencies，意指項(xiàng)目中使用到的，但是沒(méi)有顯式聲明的依賴，這里是spring-context。這種依賴意味著潛在的風(fēng)險(xiǎn)，當(dāng)前項(xiàng)目直接在使用它們，例如有很多相關(guān)的Java import聲明，而這種依賴是通過(guò)直接依賴傳遞進(jìn)來(lái)的，當(dāng)升級(jí)直接依賴的時(shí)候，相關(guān)傳遞性依賴的版本也可能發(fā)生變化，這種變化不易察覺(jué)，但是有可能導(dǎo)致當(dāng)前項(xiàng)目出錯(cuò)。例如由于接口的改變，當(dāng)前項(xiàng)目中的相關(guān)代碼無(wú)法編譯。這種隱藏的、潛在的威脅一旦出現(xiàn)，就往往需要耗費(fèi)大量的時(shí)間來(lái)查明真相。因此，顯式聲明任何項(xiàng)目中直接用到的依賴。

結(jié)果中還有一個(gè)重要的部分是Unused declared dependencies，意指項(xiàng)目中未使用的，但顯式聲明的依賴，這里有spring-core和spring-beans。需要注意的是，對(duì)于這樣一類(lèi)依賴，我們不應(yīng)該簡(jiǎn)單地直接刪除其聲明，而是應(yīng)該仔細(xì)分析。由于dependency:analyze只會(huì)分析編譯主代碼和測(cè)試代碼需要用到的依賴，一些執(zhí)行測(cè)試和運(yùn)行時(shí)需要的依賴它就發(fā)現(xiàn)不了。很顯然，該例中的spring-core和spring-beans是運(yùn)行Spring Framework項(xiàng)目必要的類(lèi)庫(kù)，因此不應(yīng)該刪除依賴聲明。當(dāng)然，有時(shí)候確實(shí)能通過(guò)該信息找到一些沒(méi)用的依賴，但一定要小心測(cè)試。

到此這篇關(guān)于Maven坐標(biāo)和依賴的實(shí)現(xiàn)示例的文章就介紹到這了,更多相關(guān)Maven坐標(biāo)和依賴內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！