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

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

  4.0.0

  com.cc.maven
  project-a
  1.0.0
  jar

 
   
      com.cc.maven
      project-b
      1.0.0
     
           
             com.cc.maven
              project-c
           
   
   

   
      com.cc.maven
      project-b
      1.1.0
   

 


上述代码中，项目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;
}

这两个简单的方程式计算圆的周长和面积，有经验的程序员一眼就能看出问题，使用字面量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;
}

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

  4.0.0

  com.juven.mvnbook.account
  account-email
  1.0.0-SNAPSHOT
  Account Email

 
     2.5.6
 

 
   
      org.springframework
      spring-core
      ${springframework.version}
   

     
      org.springframework
      spring-context
      ${springframework.version}
   

     
      org.springframework
      spring-context-support
      ${springframework.version}
   
 


这里简单使用到了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工具可以帮助分析当前项目的依赖