Maven的排除依赖、归类依赖、优化依赖

排除依赖

传递性依赖会给项目隐式地引入很多依赖，着极大简化了项目依赖的管理，但是有些时候这种特性也会带来问题。例如，当前项目有一个第三方依赖，而这个第三方依赖由于某些原因依赖了另一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT的不稳定性会直接影响到当前的项目。这时就需要排除掉该SNAPSHOT，并且在当前项目中声明该类库的某个正式发布的版本。还有一些情况，你可能也想要替换掉某个传递性依赖，比如Sun JTA API，Hibernate依赖与这个JAR，但是由于版权的因素，该类库不在中央仓库中，而Apache Geronimo项目有一个对应的实现。这时你就可以排除Sun JAT API，而声明Geronimo的JTA API实现。

<project>
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.cc.maven</groupId>
  <artifactId>project-a</artifactId>
  <version>1.0.0</version>
  <packaging>jar</packaging>


  <dependencies>
    <dependency>
      <groupId>com.cc.maven</groupId>
      <artifactId>project-b</artifactId>
      <version>1.0.0</version>
      <exclusions>
            <exclusion>
             <groupId>com.cc.maven</groupId>
              <artifactId>project-c</artifactId>
            </exclusion>
    </exclusions>
    </dependency>

    <dependency>
      <groupId>com.cc.maven</groupId>
      <artifactId>project-b</artifactId>
      <version>1.1.0</version>
    </dependency>

  </dependencies>
</project>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30

上述代码中，项目A依赖于项目B，但是由于一些原因，不想引入传递性依赖C，而是自己显式声明对项目C 1.1.0版本的依赖。代码中使用exclusions元素声明排除依赖，exclusions可以包含一个或者多个exclusion子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明exclusion的时候只需要groupId和artifactId，而不需要version元素，这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说，maven解析后的依赖中，不可能出现groupId和artifactId项目，但是version不同的两个依赖。该例的依赖解析逻辑如下所示： 

归类依赖

关于Spring Framework的依赖有很多，他们来自同一个项目的不同模块。因此所有这些依赖的版本都是相同的，可以知道，如果将来想要升级Spring Framework的话，这些依赖版本也会一起升级。这一情况在java中也似曾相识，考虑代码如下：

public double c(double r){
    return 2 * 3.14 * r;
}

public double s(double r){
    return 3.14 * r * r;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7

这两个简单的方程式计算圆的周长和面积，有经验的程序员一眼就能看出问题，使用字面量3.14显然不合适，应该定义一个常量并在方法中使用，如下：

public final double PI = 3.14;

public double c(double r){
    return 2 * PI * r;
}

public double s(double r){
    return PI * r * r;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

使用常量不仅可以使代码变得更加简洁，更重要的是可以避免重复，只需要更改一处，降低了错误的概率。 
使用maven属性归类依赖：

<project>
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.juven.mvnbook.account</groupId>
  <artifactId>account-email</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <name>Account Email</name>


  <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-context</artifactId>
      <version>${springframework.version}</version>
    </dependency>

     <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context-support</artifactId>
      <version>${springframework.version}</version>
    </dependency>
  </dependencies>
</project>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33

这里简单使用到了Maven的属性，首先使用properties元素定义了Maven的属性，该例子中定义了一个springframework.version子元素，其值为2.5.6，有了这个属性之后，Maven运行的时候，会将POM中所有${springframework.version}替换成2.5.6，也就是说，可以使用${}的方式来引用Maven的属性，然后将所有Spring Framework依赖的版本值用这一属性引用。这个和在java中常量PI替换3.14是同样的道理，只是语法不同而已。

优化依赖

在软件开发的过程中，程序员会通过重构等方式不断地优化自己的代码，使其变得更简洁、更灵活。同理，程序员也应该能够对maven项目的依赖了然于胸，并对其优化，如去除多余的依赖，显式声明某些必要的依赖。 
maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围。对于一些依赖冲突，也能进行调解，以确保任何一个构件只能唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖。 
可以通过运行如下命令查看当前项目的已解析依赖：mvn dependency:list 

将直接在当前POM声明的依赖定义为顶层依赖，而这些顶层依赖的依赖则定义为第二层依赖，以此类推，有第三、第四层依赖。当这些依赖经过Maven解析之后，就会构成一个依赖树，通过这颗依赖树，就能够很清楚地看到某个依赖是通过哪条路径引入的。可以运行如下命令查看当前项目的依赖树：mvn dependency:tree 

使用mvn dependency:list和mvn dependency:tree可以帮助我们详细了解项目中所有的依赖的具体详细，在此基础上，还有mvn dependency:analyze工具可以帮助分析当前项目的依赖