Maven實戰讀書筆記（三）：Maven依賴

3.1 依賴的配置

一個依賴聲明能夠包含下面元素：

<dependencies>
    <dependency>
        <groupId></groupId>
        <artifactId></artifactId>
        <version></version>
        <type></type>
        <scope></scope>
        <optional></optional>
        <exclusions>
            <exclusion>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

groupId、artifactId、version依賴的基本座標。
type：依賴的類型，對應於項目座標定義的packaging，默認：jar。
scope：依賴的範圍。
optional：標誌依賴是否可選，true/false。
exclusions：用來排除傳遞性依賴。

3.2 依賴範圍

依賴範圍是用來控制依賴於三種classpath(編譯classpath、測試classpath、運行classpath)的關係。
Maven的依賴範圍有以下幾種：
compile:編譯依賴範圍，默認值，對三種classpath都有效。
test:測試依賴範圍，只對測試classpath有效，典型例子如：Junit
provided:已提供依賴範圍，對編譯和測試classpath有效，但在運行時無效，典型例子如：servlet-api，運行時由容器提供。
runtime:運行時依賴範圍，對測試和運行classpath有效，編譯主代碼時無效，典型例子如：JDBC驅動實現，編譯時只須要JDK提供的JDBC接口，運行才須要具體的實現。
system:系統依賴範圍，對編譯和測試classpath有效，但在運行時無效。使用該範圍時，必須經過systemPath元素指定依賴的路徑。

<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:導入依賴範圍，該範圍不會對三種classpath產生實際應用，會將目標POM中的dependencyManagement配置導入合併到當前POM的dependencyManagement元素中。

3.3 傳遞性依賴和依賴範圍

Maven的傳遞性依賴是指不須要考慮你依賴的庫文件所須要依賴的庫文件，可以將依賴模塊的依賴自動的引入。

依賴的範圍不只能夠控制依賴與三種classpath的關係，還會對傳遞性依賴產生影響。假設A依賴於B，B依賴於C，則說A對於B是第一直接依賴，B對C是第二直接依賴，A對於C是傳遞依賴。第一直接依賴範圍和第二直接依賴範圍決定了傳遞性依賴的範圍，其結果以下：

第二直接依賴範圍是`compile`時，傳遞性依賴範圍與第一直接依賴範圍一致；
  第二直接依賴範圍是`test`時，依賴不會得以傳遞；
  第二直接依賴範圍是`provided`時，只傳遞第一直接依賴範圍也爲provided的；
  第二直接依賴範圍是`runtime`時，傳遞性依賴的範圍與第一直接依賴範圍一致，`compile`例如，此時的傳遞性依賴範圍爲`runtime`。

3.4 依賴調解

通常狀況下，只關心項目的直接依賴，而不關心直接依賴引入的傳遞性依賴，但當傳遞性依賴出現問題時，須要知道該傳遞性依賴是怎麼引進來的。
Maven依賴調解第一原則:路徑最近者優先，如：A->B->C->X(1.0)、A->D-X(2.0)，則X的2.0版本會被解析使用；
Maven依賴調解第二原則:第一聲明者優先，如:A->B->X(1.0)、A->D->X(2.0),若B的依賴聲明在D以前，則使用X的1.0版本，不然使用X的2.0版本。

3.5 可選依賴

假設有下面的依賴關係:A->B、B->X(可選)、B->Y(可選)，因爲X和Y是可選的，因此依賴不會傳遞，X和Y不會對A有任何影響。

可選依賴的必要性:項目B實現2種特性，特性一依賴於X，特性二依賴於Y，並且這兩個特性是互斥的，用戶不可能同時適用這兩個特性，這時候可選依賴就有用了。
原則上說，是不該該使用可選依賴的，根據面向對象的單一職責性原則，該原則一樣適用於Maven項目的規劃。

3.6 最佳實踐

1）排除依賴

傳遞性依賴會給項目隱式的引入不少依賴，這極大的簡化了項目依賴的管理，可是有時某些依賴會帶來問題，這時須要把帶來問題的依賴排除掉。

2）歸類依賴
來自同一個項目的不一樣模塊，其版本號應該是相同的，如springframework項目有spring-core、spring-beans模塊，對這些模塊的版本號經過屬性定義，再進行引用，這樣能夠進行版本的總體升級:

<properties>
        <springframework.version>4.3.13.RELEASE</springframework.version>
    </properties>
    <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>

3）優化依賴

去掉多餘的依賴，顯示聲明某些必要的依賴。
經過mvn dependency:list 查看項目已解析的依賴
經過mvn dependency:tree 查看項目的依賴樹