正如前面文章所述，Maven 的一大功能是管理項(xiàng)目依賴。為了能自動(dòng)化地解析任何一個(gè) Java 構(gòu)件， Maven 就必須將它們唯一標(biāo)識(shí)，這就依賴管理的底層基礎(chǔ)——坐標(biāo)。本節(jié)將詳細(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)該來自于平面幾何。在一個(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)概念之前，我們無法使用任何一種方式 來唯一標(biāo)識(shí)所有這些構(gòu)件。因此，當(dāng)需要用到 Spring Franework 依賴的時(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)頁等工作上面。
沒有統(tǒng)一的規(guī)范、統(tǒng)一的法則，該工作就無法自動(dòng)化。重復(fù)地搜索、瀏覽網(wǎng)頁和下載類似的 jar文件，這本就應(yīng)該交給機(jī)器來做。而機(jī)器工作必須基于預(yù)定義的規(guī)則， Maven 定義了這樣一組規(guī)則：世界上任何一個(gè)構(gòu)件都可以使用Maven 坐標(biāo)唯一標(biāo)識(shí)， Maven 坐標(biāo)的元素包括 groupld、artifactld、version、packaging、clasifer?，F(xiàn)在，只要我們提供正確的坐標(biāo)元素， Maven 就能找到對(duì)應(yīng)的構(gòu)件。比如說，當(dāng)需要使用 Java5 平臺(tái)上TestNG的5.8版本時(shí)，就告訴 Maven: “groupld =org.testng; artifactld =testng; version=5.8; classifier =jdk15”, Maven 就會(huì)從倉庫中尋找相應(yīng)的構(gòu)件供我們使用。
也許你會(huì)奇怪， “Maven 是從哪里下載構(gòu)件的呢?” 答案其實(shí)很簡單， Maven 內(nèi)置了一個(gè)中央倉庫的地址 (http://repol.maven.ong/maven2), 該中央倉庫包含了世界上大部分流行的開源項(xiàng)目構(gòu)件， Maven 會(huì)在需要的時(shí)候去那里下載。
在我們開發(fā)自己項(xiàng)目的時(shí)候，也需要為其定義適當(dāng)?shù)淖鴺?biāo)，這是 Maven 強(qiáng)制要求的。 在這個(gè)基礎(chǔ)上，其他Maven 項(xiàng)目才能引用該項(xiàng)目生成的構(gòu)件，見下圖。
2?? 坐標(biāo)詳解
Maven 坐標(biāo)為各種構(gòu)件引入了秩序，任何一個(gè)構(gòu)件都必須明確定義自己的坐標(biāo)，而 一 組 Maven 坐標(biāo)是通過一些元素定義的，它們是 groupld、artifactld、version、packaging、classifier。先看一組坐標(biāo)定義，如下：
<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus-indexer</artifactId>
<version>2.0.0<Nersion>
<packaging>jar<packaging>
這是 nexus-indexer 的坐標(biāo)定義， nexus-indexer 是一個(gè)對(duì)Maven 倉庫編纂索引并提供搜索功能的類庫，它是 Nexus 項(xiàng)目的一個(gè)子模塊。后面會(huì)詳細(xì)介紹 Nexus。上述代碼片段中，其坐標(biāo)分別為 groupld:org.sonatype.nexus、artifactld:nexus-indexer、version:2.0.0、packaging: jar, 沒有 classifier。下面詳細(xì)解釋一下各個(gè)坐標(biāo)元素：
-
groupId：定義當(dāng)前 Maven 項(xiàng)目隸屬的實(shí)際項(xiàng)目。首先， Maven 項(xiàng)目和實(shí)際項(xiàng)目不一定是一對(duì)一的關(guān)系。比如Spring Framework這一實(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)目隸屬的組織或公司。原因很簡單，一個(gè)組織下會(huì)有很多實(shí)際項(xiàng)目，如果groupId只定義到組織級(jí)別， 而后面我們會(huì)看到，artifactId只能定義Maven 項(xiàng)目(模塊), 那么實(shí)際項(xiàng)目這個(gè)層將難以定義。最后，groupId的表示方式與Java包名的表示方式類似，通常與域名反向一一對(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作為開頭，如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模塊，如果沒有前綴，我們會(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)的概念。后面文章會(huì)詳細(xì)討論版本管理內(nèi)容。 -
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文件， 不過這不是絕對(duì)的。其次，打包方式會(huì)影響到構(gòu)建的生命周期，比如 jar打包和 war打包會(huì)使用不同的命令。最后，當(dāng)不定義packaging的時(shí)候，Maven 會(huì)使用默認(rèn)值 jar。 -
classifier：該元素用來幫助定義構(gòu)建輸出的一些附屬構(gòu)件。附屬構(gòu)件與主構(gòu)件對(duì)應(yīng)， 如上例中的主構(gòu)件是nexus-indexer-2.0.0.jar, 該項(xiàng)目可能還會(huì)通過使用一些插件生成如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-javadoe.jar。這里還要強(qiáng)調(diào)的一點(diǎn)是，packaging 并非一定與構(gòu)件擴(kuò)展名對(duì)應(yīng)，比如 packaging 為 maven-plugin 的構(gòu)件擴(kuò)展名為 jar。
此外， Maven 倉庫的布局也是基于Maven 坐標(biāo)，這一點(diǎn)會(huì)在介紹 Maven 倉庫的時(shí)候詳細(xì)解釋。理解清楚城市中地址的定義方式后，郵遞員就能夠開始工作了；同樣地，理解清楚 Maven 坐標(biāo)之后，我們就能開始討論Maven 的依賴管理了。
3?? 依賴的配置
上面介紹了maven配置文件中一些簡單的依賴配置，可以看到依賴會(huì)有基本的 groupId、artifactId 和 version 等元素組成。其實(shí)一個(gè)依賴聲明還可以包含如下的一些元素：
<project>
...
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<type>...</type>
<scope>...</scope>
<optional>...</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è)依賴來說，基本坐標(biāo)是最重要的， Maven 根據(jù)坐標(biāo)才能找到需要的依賴。 -
type：依賴的類型，對(duì)應(yīng)于項(xiàng)目坐標(biāo)定義的packaging。大部分情況下，該元素不必聲明，其默認(rèn)值為jar。 -
scope：依賴的范圍，后面會(huì)詳細(xì)介紹。 -
optional：標(biāo)記依賴是否可選，后面會(huì)詳細(xì)介紹。 -
exclusions：用來排除傳遞性依賴，后面會(huì)詳細(xì)介紹。
大部分依賴聲明只包含基本坐標(biāo)，然而在一些特殊情況下，其他元素至關(guān)重要。后面會(huì)對(duì)它們的原理和使用方式詳細(xì)介紹。
4?? 依賴范圍
本節(jié)將詳細(xì)解釋什么是依賴范圍，以及各種依賴范圍的效果和用途。
首先需要知道， Maven 在編譯項(xiàng)目主代碼的時(shí)候需要使用一套 classpath。 在上例中，編譯項(xiàng)目主代碼的時(shí)候需要用到 sping-core, 該文件以依賴的方式被引入到 classpath中。其次 ，Maven 在編譯和執(zhí)行測試的時(shí)候會(huì)使用另外一套 classpath。最后，實(shí)際運(yùn)行Maven 項(xiàng)目的時(shí)候，又會(huì)使用一套 classpath, 上例中的 spring-core 需要在該classpath 中，而JUnit 則不需要。
依賴范圍就是用來控制依賴與這三種 classpath ( 編譯 classpath、 測試 classpath、 運(yùn)行 classpath) 的關(guān)系，Maven 有以下幾種依賴范圍：
-
compile：編譯依賴范圍。如果沒有指定，就會(huì)默認(rèn)使用該依賴范圍。使用此依賴范圍 的 Maven 依賴，對(duì)于編譯、測試、運(yùn)行三種 classpath 都有效。典型的例子是 spring-core, 在編譯、測試和運(yùn)行的時(shí)候都需要使用該依賴。 -
test：測試依賴范圍。使用此依賴范圍的Maven 依賴，只對(duì)于測試 classpath 有效，在 編譯主代碼或者運(yùn)行項(xiàng)目的使用時(shí)將無法使用此類依賴。典型的例子是JUnit, 它只有在編譯測試代碼及運(yùn)行測試的時(shí)候才需要。 -
provided：已提供依賴范圍。使用此依賴范圍的Maven 依賴，對(duì)于編譯和測試 classpath有效，但在運(yùn)行時(shí)無效。典型的例子是 servlet-api, 編譯和測試項(xiàng)目的時(shí)候需要 該依賴，但在運(yùn)行項(xiàng)目的時(shí)候，由于容器已經(jīng)提供，就不需要 Maven 重復(fù)地引入一遍。 -
runtime：運(yùn)行時(shí)依賴范圍。使用此依賴范圍的 Maven 依賴，對(duì)于測試和運(yùn)行 classpath有效，但在編譯主代碼時(shí)無效。典型的例子是JDBC 驅(qū)動(dòng)實(shí)現(xiàn)，項(xiàng)目主代碼的編譯只需要JDK 提供的JDBC 接口，只有在執(zhí)行測試或者運(yùn)行項(xiàng)目的時(shí)候才需要實(shí)現(xiàn)上述接口的具體JDBC 驅(qū)動(dòng)。 -
system：系統(tǒng)依賴范圍。該依賴與三種 classpath 的關(guān)系，和 provided 依賴范圍完全一致。但是，使用system 范圍的依賴時(shí)必須通過systemPath 元素顯式地指定依賴文件 的路徑。由于此類依賴不是通過Maven 倉庫解析的，而且往往與本機(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í)際的影響，在后續(xù)介紹 Maven 依賴和 dependeneyManagement 的時(shí)候會(huì)詳細(xì)介紹此依賴范圍。
上述除 import 以外的各種依賴范圍與三種 classpath的關(guān)系如下所示。
| 依賴范圍（Scope） | 對(duì)于編譯classpath有效 | 對(duì)于測試classpath有效 | 對(duì)于運(yùn)行時(shí)classpath有效 | 例子 |
|---|---|---|---|---|
| compile | ?? | ?? | ?? | spring-core |
| test | - | ?? | - | Junit |
| provided | ?? | ?? | - | servlet-api |
| runtime | - | ?? | ?? | JDBC驅(qū)動(dòng) |
| system | ?? | ?? | - | 本地的 maven倉庫之外的類庫文件 |
5?? 傳遞性依賴
考慮一個(gè)基于Spring Framework 的項(xiàng)目，如果不使用Maven, 那么在項(xiàng)目中就需要手動(dòng) 下載相關(guān)依賴。由于Spring Framework 又會(huì)依賴于其他開源類庫，因此實(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ī)制可以很好地解決這一問題。例如現(xiàn)在有一個(gè)名為 account-email 的項(xiàng)目，該項(xiàng)目有一個(gè) org.springframework:spring-core:2.5.6 的依賴，而實(shí)際上 spring-core 也有它自己的依賴，我們可以直接訪問位于中央倉庫的該構(gòu)件的POM: http://repol.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>
該依賴沒有聲明依賴范圍，那么其依賴范圍就是默認(rèn)的compile。 同時(shí)回顧—下 account-email, spring-core 的依賴范圍也是 compile。account-mail 有一個(gè)compile 范圍的 spring-core 依賴， sping-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)目中。
依賴范圍不僅可以控制依賴與三種 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, 我們說A 對(duì)于B是第一直接依賴， B對(duì)于C 是第二直接依賴， A 對(duì)于C 是傳遞性依賴。第一直接依賴的范圍和第二直接依賴的范圍決定了傳遞性依賴的范圍，如下表所示，最左邊一列表示第一直接依賴范圍，最上面一行表示第二直接依賴范圍，中間的交叉單元格則表示傳遞性依賴范圍。
| compile | test | provided | runtime | |
|---|---|---|---|---|
| compile | compile | - | - | runtime |
| test | test | - | - | test |
| provided | provided | - | provided | provided |
| runtime | runtime | - | - | runtime |
為了能幫助大家更好地理解上表，再舉個(gè)例子。 account-email 項(xiàng)目有一個(gè) com.icegreen:greenmail:1.3.1b 的直接依賴，我們說這是第一直接依賴，其依賴范圍是test; 而 greenmail又有一個(gè) javax.mail:mail:1.4 的直接依賴，我們說這是第二直接依賴，其依賴范圍是 compile。 顯然 javax.mail:mail:1.4 是 account-email 的傳遞性依賴，對(duì)照上表可以知道，當(dāng)?shù)谝恢苯右蕾嚪秶鸀?code>test, 第二直接依賴范圍是 compile 的時(shí)候，傳遞性依賴的范圍是test, 因此 javax.mail:mail:1.4 是 account-email 的一個(gè)范圍是 test的傳遞性依賴。
仔細(xì)觀察一下上表,可以發(fā)現(xiàn)這樣的規(guī)律：當(dāng)?shù)诙苯右蕾嚨姆秶?compile 的時(shí)候，傳遞性依賴的范圍與第一直接依賴的范圍一致；當(dāng)?shù)诙苯右蕾嚨姆秶?test 的時(shí)候， 依賴不會(huì)得以傳遞；當(dāng)?shù)诙苯右蕾嚨姆秶?provided 的時(shí)候，只傳遞第一直接依賴范圍 也為provided 的依賴，且傳遞性依賴的范圍同樣為 provided; 當(dāng)?shù)诙苯右蕾嚨姆秶莚untime 的時(shí)候，傳遞性依賴的范圍與第一直接依賴的范圍一致，但 compile 例外，此時(shí)傳遞性依賴的范圍為 runtime。
6?? 依賴調(diào)解
Maven 引入的傳遞性依賴機(jī)制， 一方面大大簡化和方便了依賴聲明，另一方面，大部 分情況下我們只需要關(guān)心項(xiàng)目的直接依賴是什么，而不用考慮這些直接依賴會(huì)引入什么傳遞性依賴。但有時(shí)候，當(dāng)傳遞性依賴造成問題的時(shí)候，我們就需要清楚地知道該傳遞性依賴是從哪條依賴路徑引入的。
例如，項(xiàng)目A 有這樣的依賴關(guān)系： A->B->C->X(1.0)、A->D->X(2.0), X 是 A 的傳遞性依賴，但是兩條依賴路徑上有兩個(gè)版本的X, 那么哪個(gè)X 會(huì)被 Maven 解析使用呢? 兩個(gè)版本都被解析顯然是不對(duì)的，因?yàn)槟菚?huì)造成依賴重復(fù)，因此必須選擇一個(gè)。Maven 依賴調(diào)解 (Dependency Mediation) 的第一原則是：路徑最近者優(yōu)先。該例中X(1.0) 的路徑長度為 3 , 而 X(2.0) 的路徑長度為2, 因此X(2.0) 會(huì)被解析使用。
依賴調(diào)解第一原則不能解決所有問題，比如這樣的依賴關(guān)系； A->B->Y(1.0)、A-> C->Y(2.0), Y(1.0) 和 Y(2.0) 的依賴路徑長度是一樣的，都為2。那么到底誰會(huì)被解析
使用呢? 在Maven 2.0.8及之前的版本中，這是不確定的，但是從 Maven 2.0.9開始，為了盡可能避免構(gòu)建的不確定性， Maven 定義了依賴調(diào)解的第二原則：第一聲明者優(yōu)先。
在依賴路徑長度相等的前提下，在POM 中依賴聲明的順序決定了誰會(huì)被解析使用，順序最靠前的那個(gè)依賴優(yōu)勝。該例中，如果B 的依賴聲明在C 之前，那么Y(1.0) 就會(huì)被解析使用。
7?? 可選依賴
假設(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ì)得以傳遞。換句話說， X、Y 將不會(huì)對(duì) A有任何影響，如下圖所示。
為什么要使用可選依賴這一特性呢? 可能項(xiàng)目B 實(shí)現(xiàn)了兩個(gè)特性，其中的特性一依賴于X, 特性二依賴于Y, 而且這兩個(gè)特性是互斥的，用戶不可能同時(shí)使用兩個(gè)特性。比如 B 是一個(gè)持久層隔離工具包，它支持多種數(shù)據(jù)庫，包括 MySQL、PostgreSQL 等，在構(gòu)建這個(gè)
工具包的時(shí)候，需要這兩種數(shù)據(jù)庫的驅(qū)動(dòng)程序，但在使用這個(gè)工具包的時(shí)候，只會(huì)依賴一種數(shù)據(jù)庫。
項(xiàng)目B 的依賴聲明見下邊代碼清單。
<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 這兩個(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ù)庫，那么在項(xiàng)目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>
最后，關(guān)于可選依賴需要說明的一點(diǎn)是，在理想的情況下，是不應(yīng)該使用可選依賴的。 前面我們可以看到，使用可選依賴的原因是某一個(gè)項(xiàng)目實(shí)現(xiàn)了多個(gè)特性，在面向?qū)ο笤O(shè)計(jì)中，有個(gè)單一職責(zé)性原則，意指一個(gè)類應(yīng)該只有一項(xiàng)職責(zé)，而不是糅合太多的功能。
這個(gè)原則在規(guī)劃 Maven 項(xiàng)目的時(shí)候也同樣適用。在上面的例子中，更好的做法是為MySQL 和 PostgreSQL分別創(chuàng)建一個(gè) Maven 項(xiàng)目 ， 基于同樣的 groupId 分配不同的artifactId, 如 com.xiaoshan. mvnbook:project-b-mysql 和 com.xiaoshan. mvnbook:project-b-postgresgl, 在各自的 POM 中聲明對(duì)應(yīng)的JDBC 驅(qū)動(dòng)依賴，而且不使用可選依賴，用戶則根據(jù)需要選擇使用 pro-ject-b-mysql 或者 project-b-postgresql。 由于傳遞性依賴的作用，就不用再聲明JDBC 驅(qū)動(dòng)依賴。
8?? 最佳實(shí)踐
Maven 依賴涉及的知識(shí)點(diǎn)比較多，在理解了主要的功能和原理之后，最需要的當(dāng)然就是前人的經(jīng)驗(yàn)總結(jié)了，我們稱之為最佳實(shí)踐。本小節(jié)歸納了一些使用Maven 依賴常見的技 巧，方便用來避免和處理很多常見的問題。
8.1 排除依賴
傳遞性依賴會(huì)給項(xiàng)目隱式地引入很多依賴，這極大地簡化了項(xiàng)目依賴的管理，但是有些時(shí)候這種特性也會(huì)帶來問題。例如，當(dāng)前項(xiàng)目有一個(gè)第三方依賴，而這個(gè)第三方依賴由于某些原因依賴了另外一個(gè)類庫的SNAPSHOT 版本，那么這個(gè) SNAPSHOT 就會(huì)成為當(dāng)前項(xiàng)目的傳遞性依賴，而 SNAPSHOT 的不穩(wěn)定性會(huì)直接影響到當(dāng)前的項(xiàng)目。這時(shí)就需要排除掉該SNAPSHOT, 并且在當(dāng)前項(xiàng)目中聲明該類庫的某個(gè)正式發(fā)布的版本。還有 一些情況，你可能也想要替換某個(gè)傳遞性依賴，比如 Sun JTA API, Hibernate 依賴于這個(gè)JAR, 但是由于版權(quán)的因素，該類庫不在中央倉庫中，而 Apache Geronimo項(xiàng)目有一個(gè)對(duì)應(yīng)的實(shí)現(xiàn)。這時(shí)你就可以排除 Sun JAT API, 再聲明 Geronimo 的 JTA API實(shí)現(xiàn)，見如下代碼清單。
<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>
<exclusions>
<exclusion>
<groupId>com.xiaoshan.mvnbook</groupId>
<artifactId>project-c</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.xiaoshan.mvnbook</groupId>
<artifactId>project-c</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>
</project>
上述代碼中，項(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)橹恍枰?groupId 和 artifactId就能唯一定位依賴圖中的某個(gè)依賴。換句話說，Maven解析后的依賴中，不可能出現(xiàn) groupId 和artifactId相同，但是version不同的兩個(gè)依賴。該例的依賴解析邏輯如下圖所示。
8.2 歸類依賴
在前面文章中介紹過，在一個(gè)項(xiàng)目中可能有很多關(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, 它們是來自同一項(xiàng)目的不同模塊。
因此，所有這些依賴的版本都是相同的，而且可以預(yù)見，如果將來需要升級(jí)SpringFramework, 這些依賴的版本會(huì)一起升級(jí)。這一情況在Java中似曾相識(shí)，考慮如下簡單代碼。
public double c(double r){
return 2 * 3.14 * r;
}
public double s(double r){
return 3. 14 * r * r;
}
這兩個(gè)簡單的方程式計(jì)算圓的周長和面積，稍微有經(jīng)驗(yàn)的程序員一眼就會(huì)看出一個(gè)問題，使用字面量(3.14)顯然不合適，應(yīng)該使用定義一個(gè)常量并在方法中使用，見如下代碼清單。
public final double PI = 3.14;
public double c(double r){
return 2 * PI * r;
}
public double s(double r){
return PI * r * r;
}
使用常量不僅讓代碼變得更加簡潔，更重要的是可以避免重復(fù)，在需要更改 PI的值的
時(shí)候，只需要修改一處，降低了錯(cuò)誤發(fā)生的概率。
同理，對(duì)于account-email 中這些SpringFramework來說，也應(yīng)該在一個(gè)唯一的地方定義
版本，并且在dependency聲明中引用這一版本。這樣，在升級(jí)SpringFramework的時(shí)候就只需要修改一處，實(shí)現(xiàn)方式見如下代碼清單。
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xiaoshan.mvnbook.account</groupId>
<artifactId>yaccount-email</artifactId>
<name>AccountEmail</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</artifactIds>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
</project>
這里簡單用到了Maven 屬性(后面文章會(huì)詳細(xì)介紹 Maven 屬性) , 首先使用 properties 元 素定義Maven 屬性，該例中定義了一個(gè) springframework. version 子元素，其值為 2.5.6。有了這個(gè)屬性定義之后， Maven 運(yùn)行的時(shí)候會(huì)將 POM 中的所有的 ${springframework.version} 替換成實(shí)際值 2.5.6。也就是說，可以使用美元符號(hào)$和大括弧 {和}環(huán)繞的方式引用 Maven 屬性。然后，將所有 Spring Framework 依賴的版本值用這一屬性引用表示。這和在Java 中用常量 PI 替換 3.14 是同樣的道理，不同的只是語法。
8.3 優(yōu)化依賴
在軟件開發(fā)過程中，程序員會(huì)通過重構(gòu)等方式不斷地優(yōu)化自己的代碼，使其變得更簡 潔、更靈活。同理，程序員也應(yīng)該能夠?qū)aven 項(xiàng)目的依賴了然于胸，并對(duì)其進(jìn)行優(yōu)化， 如去除多余的依賴，顯式地聲明某些必要的依賴。
本文前面的內(nèi)容已經(jī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
在項(xiàng)目中執(zhí)行該命令，結(jié)果如圖所示。
上圖顯示了所有 account-email 的已解析依賴，同時(shí)，每個(gè)依賴的范圍也得以明確標(biāo)示。
在此基礎(chǔ)上，還能進(jìn)一步了解已解析依賴的信息。將直接在當(dāng)前項(xiàng)目POM 聲明的依賴 定義為頂層依賴，而這些頂層依賴的依賴則定義為第二層依賴，以此類推，有第三、第四層依賴。當(dāng)這些依賴經(jīng) Maven 解析后，就會(huì)構(gòu)成一個(gè)依賴樹，通過這棵依賴樹就能很清楚地看到某個(gè)依賴是通過哪條傳遞路徑引入的。可以運(yùn)行如下命令查看當(dāng)前項(xiàng)目的依賴樹：
mvn dependency:tree
在項(xiàng)目中執(zhí)行該命令，效果如下圖所示。
從圖中能夠看到，雖然我們沒有聲明 org.sl4j:sl4j-api:1.3 這一依賴，但它還是經(jīng)過 com.icegreen:greenmail:1.3 成為了當(dāng)前項(xiàng)目的傳遞性依賴，而且其范圍是 test。
使用 dependency:list 和 dependeney:tree 可以幫助我們詳細(xì)了解項(xiàng)目中所有依賴的具體 信息，在此基礎(chǔ)上，還有 dependency:analyze 工具可以幫助分析當(dāng)前項(xiàng)目的依賴。
為了說明該工具的用途，先將 spring-context 這一依賴刪除，然后構(gòu)建項(xiàng)目，你會(huì)發(fā)現(xiàn)編譯、測試和打包都不會(huì)有任何問題。通過分析依賴樹，可以看到 spring-context是 spring-context-support 的依賴，因此會(huì)得以傳遞到項(xiàng)目的 classpath 中。現(xiàn)在再運(yùn)行如下命令：
mvn dependency:analyze
結(jié)果如下圖所示。
該結(jié)果中重要的是兩個(gè)部分。首先是Used undeclared dependencies, 意指項(xiàng)目中使用到的，但是沒有顯式聲明的依賴，這里是 spring-context。 這種依賴意味著潛在的風(fēng)險(xiǎn)，當(dāng)前項(xiàng)目直接在使用它們，例如有很多相關(guān)的Java import 聲明，而這種依賴是通過直接依賴傳遞進(jìn)來的，當(dāng)升級(jí)直接依賴的時(shí)候，相關(guān)傳遞性依賴的版本也可能發(fā)生變化，這種變化不易察覺，但是有可能導(dǎo)致當(dāng)前項(xiàng)目出錯(cuò)。例如由于接口的改變，當(dāng)前項(xiàng)目中的相關(guān)代碼無法編譯。這種隱藏的、潛在的威脅一旦出現(xiàn)，就往往需要耗費(fèi)大量的時(shí)間來查明真相。因此， 顯式聲明任何項(xiàng)目中直接用到的依賴。
結(jié)果中還有一個(gè)重要的部分是 Unused declared dependencies, 意指項(xiàng)目中未使用的，但 顯式聲明的依賴，這里有 spring-core 和 spring-beans、 需要注意的是， 對(duì)于這樣一類依賴， 我們不應(yīng)該簡單地直接刪除其聲明，而是應(yīng)該仔細(xì)分析。由于dependeney:analyze 只會(huì)分析編譯主代碼和測試代碼需要用到的依賴, 一些執(zhí)行測試和運(yùn)行時(shí)需要的依賴它就發(fā)現(xiàn)不了。 很顯然，該例中的 spring-core 和 spring-beans 是 運(yùn) 行 Spring Framework 項(xiàng)目必要的類庫，因此不應(yīng)該刪除依賴聲明。當(dāng)然，有時(shí)候確實(shí)能通過該信息找到一些沒用的依賴，但一定要小心測試。
?? 總結(jié)
本文主要介紹了Maven 的兩個(gè)核心概念：坐標(biāo)和依賴。解釋了坐標(biāo)的由來，并詳細(xì)闡述了各坐標(biāo)元素的作用及定義方式。隨后引入了一個(gè)項(xiàng)目實(shí)際的基于 Spring Framework 的模塊，包括了POM 定義、業(yè)務(wù)代碼和測試代碼。在這一直觀感受的基礎(chǔ)上，再花篇幅介紹了 Maven 依賴，包括依賴范圍、傳遞性依賴、可選依賴等概念。最后，當(dāng)然少不了關(guān)于依賴的一些最佳實(shí)踐。通過閱讀本文，大家應(yīng)該已經(jīng)能夠透徹地了解 Maven 的依賴管理機(jī)制。下一節(jié)將會(huì)介紹 Maven 的另一個(gè)核心概念：倉庫。
《【Maven教程】（三）基礎(chǔ)使用篇：入門使用指南——POM編寫、業(yè)務(wù)代碼、測試代碼、打包與運(yùn)行、使用Archetype生成項(xiàng)目骨架~》
《【Maven教程】（五）倉庫：解析Maven倉庫—布局、分類和配置，遠(yuǎn)程倉庫的認(rèn)證與部署，快照版本，依賴解析機(jī)制，鏡像和搜索服務(wù) ~》
到了這里，關(guān)于【Maven教程】（四）坐標(biāo)與依賴：坐標(biāo)概念，依賴配置、范圍、傳遞性和最佳實(shí)踐 ~的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
