maven 依赖和坐标

1、maven 坐标由groupId、artifactId、packaging、version、classifier定义。
2、classifier 用来帮助定义构建输出的一些附属构件。如，*javadoc.jar，*sources.jar。不能直接定义项目的classifier。
3、maven packaging 包括 jar、war、pom、maven-plugin、ear等。
4、依赖标签及其子标签

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

依赖范围

compile 默认。表示该依赖对主代码和测试都有效。
test 表示该依赖只对测试有效。即测试代码中 import JUnit 没有问题，但在主代码中 import JUnit就会造成编译错误。该依赖只会被加入到测试代码的classpath中。
provided 已提供依赖。编译、测试有效，运行时无效。如servlet-api,编译和测试时需要；但在运行时，由于容器已提供，不再需要。
runtime 运行时有效。测试和运行时有效，但在编译时不需要。如JDBC驱动实现，编译时只需要JDK提供的JDBC的接口；只有在执行测试和运行项目的时候才需要具体的JDBC驱动。
system 谨慎使用。

排除依赖

情景1：当前项目依赖了一个第三方依赖，但这个第三方依赖又依赖了另外一个SNAPSHOT版本的依赖，那么这个不稳定版本的依赖会影响到当前版本的稳定性。
情景2：Hibernate依赖 Sun JTA API，但由于版权的原因，该类库不存在于中央仓库，而Apache Geronimo 有一个对应的实现。这时就可以排除 Sun JTA API，再显示声明依赖 Apache Geronimo的 JPA API 实现。

    <dependency>
        <groupId>xxx</groupId>
        <artifactId>xxx</artifactId>
        <version>5.1.30</version>
        <exclusions>
            <exclusion>
            <groupId>xxx-zzz</groupId>
            <artifactId>zzz</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>xxx-zzz</groupId>
        <artifactId>zzz</artifactId>
        <version>1.1.1</version>
    </dependency>

exclusion 可以有多个；声明exclusions时不需要版本号。

可选依赖

A—>B、B->X(可选)、B->Y(可选)，那么X和Y都不会传递给A。
项目B实现了两个特性，特性一依赖X，特性二依赖Y，而这两个特性是互斥的。
比如一个持久层构件支持多种数据库，它需要多个数据库的驱动程序，但在使用它的时候，只会依赖一个数据库。

    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.30</version>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>myOracle</groupId>
        <artifactId>ojdbc6</artifactId>
        <version>11.2.0</version>
        <optional>true</optional>
    </dependency>

上面这两个依赖只对当前项目有效，当其它构件依赖当前构件时它们不会被传递。

其它构件依赖当前构件后，前者需要在其pom文件里显示声明其中一个。
理想情况下，不要使用可选依赖，写两个构件，分别实现两个特性。

依赖的传递性

比如当前项目依赖org.springframework:spring-core:2.5.6，而spring-core又依赖commons-logging，这时commons-logging就成为当前项目的依赖。
spring-core对commons-logging的依赖，可以在本地仓库里查看spring-core-x.x.x.pom看到。

依赖范围对传递性依赖的影响

当第二依赖的范围是compile时，依赖传递，传递依赖的范围和第一依赖的范围一致；当第二依赖范围是test的时候，依赖不会传递；当第二依赖范围是provided，只有第一依赖范围也是provided时，依赖传递，并且传递依赖的范围也是provided；当第二依赖范围是runtime，依赖传递，第一依赖是compile时，传递依赖是runtime,其它的都和第一依赖相同。

依赖调解

第一原则，就近原则：A->B->C->X(1.0)、A->D-X(2.0)
第二原则，pom中依赖顺序：A->B->X(1.0)、A->D-X(2.0)

优化依赖
mvn dependency:list
mvn dependency:tree
mvn dependency:analyze
Used undeclared dependencies，项目使用到但没有显示声明的。
Unused declared dependencies，项目中没有使用到但显示声明的。
Used undeclared dependencies风险：当前项目直接使用依赖A，比如通过import声明引入并使用，而A是传递依赖，当升级直接依赖时，相关传递依赖的版本也可能变化，比如A的一个接口改变，于是当前项目无法编译，不易排查错误。
Unused declared dependencies要注意：不应该简单的直接删除声明，要仔细分析。由于dependency:analyze只分析编译主代码和编译测试代码需要用到的依赖，一些执行测试和运行时需要的依赖它就发现不了。

猜你喜欢