1. 程式人生 > >Maven實戰讀書筆記(三):Maven依賴

Maven實戰讀書筆記(三):Maven依賴

aging com cti 無效 type -c 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配置導入合並到當前POMdependencyManagement元素中。
技術分享圖片

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-corespring-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 查看項目的依賴樹

Maven實戰讀書筆記(三):Maven依賴