Maven使用总结（二）：Maven依赖配置

Maven依赖配置

这一篇来聊一聊Maven的依赖配置。一个依赖声明可以包含如下一些元素：

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <dependencies>
    <dependency> 
      <groupId>net.sf.json-libgroupId> 
      <artifactId>json-libartifactId> 
      <version>2.2.2version>
      <type>jartype>
      <scope>compilescope>
      <optional>falseoptional>
      <exclusions>
        <exclusion>
          <groupId>junitgroupId>
          <artifactId>junitartifactId>
        exclusion>
      exclusions>
      <classifier>jdk15classifier> 
    dependency> 
  <dependencies>
project>

下面借来分别介绍这些元素。

1. groupId
   依赖的基本坐标，参见上一章节。
2. artifactId
   依赖的基本坐标，参见上一章节。
3. version
   依赖的基本坐标，参见上一章节。
4. type
   依赖类型，参见上一章节
5. scope
   依赖范围，有如下备选值：
   
   • compile
     编译依赖范围，对于编译、测试、运行三种classpath都有效，也就是在编译、测试、运行的时候都需要该依赖。
   • test
     测试以来范围。只对于测试classpath有效，只在测试的时候需要该依赖。典型的如junit。
   • provided
     已提供依赖范围。对于编译、测试两种classpath有效，运行时classpath无效。也就是在编译、测试时候都需要该依赖，运行时不需要。典型的如servlet。
   • runtime
     运行时依赖范围。对于测试、运行两种classpath有效，编译classpath无效。在编译时不需要，典型的如jdbc驱动实现。
   • system
     系统依赖范围。与provided类似，唯一的不同是必须明确的指定被依赖的构件在系统中的路径。典型的如本地的jar包，没有导入仓库中，需要从本地引用。例如：
     
javax.sql
jdbc-stdext
2.0
system
${java.home}/lib/rt.jar

   • import
     导入依赖范围。如果需要完全复制一个已经存在依赖配置，可以使用导入依赖范围，将其导入，节省重复的配置。一般被导入的构件类型为pom。例如：
     
com.qupeng.test.maven
maven-parent
1.2.3-beta-1
pom
import

6. optional
   依赖是否可选。要理解optional元素，必须理解传递性依赖。我们在为一个项目配置依赖的时候，被依赖的构件也很会依赖其他的构件，那么这些构件我们是不是也需要配置呢？答案肯定是不需要的，传递性依赖替我们解决了这个问题，它让我们只需要配置项目直接依赖的构件，而不需要关心这些构件的依赖关系。但是这种便利性也带来了一些副作用，例如依赖的冲突。所以maven又提供了一些机制，让我们可以在一定程度上控制传递依赖，optional就是其中一个。
   我们还需要理解两个概念，第一直接依赖和第二直接依赖。假设A依赖B，B依赖C，那么A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖和第二直接依赖的范围决定了传递性依赖的范围。如下表，第一列是第一直接依赖范围，第一行是第二直接依赖范围，中间区域是传递依赖范围。

第一直接依赖\第二直接依赖	compile	test	provided	runtime
compile	compile	-	-	runtime
test	test	-	-	test
provided	provided	-	provided	provided
runtime	runtime	-	-	runtime

如果我们的模块X直接依赖A，B两个构件，但是依赖X的项目Y最终只依赖A，B中的一个，而不是两个都依赖，就可以在X中将A，B配置为false，这样Y对A，B就没有传递性依赖了，Y必须明确配置对A或B的依赖。
例如：X依赖mysql和postgresql
X


mysql
mysql-connector-java
5.1.10
true


postgresql
postgresql
8.4-701.jdbc3
true


Y必须显式配置其中一个依赖：
Y


mysql
mysql-connector-java
5.1.10
true


7. exclusions
用来排除传递依赖。例如有的传递性依赖的构件版本不稳定或与其他依赖有冲突，就可以使用exclusions元素来排除传递性依赖。

  <dependencies>
    <dependency> 
      <groupId>net.sf.json-libgroupId> 
      <artifactId>json-libartifactId> 
      <version>2.2.2version>
      <type>jartype>
      <scope>compilescope>
      <optional>falseoptional>
      <exclusions>
        <exclusion>
          <groupId>junitgroupId>
          <artifactId>junitartifactId>
        exclusion>
      exclusions>
      <classifier>jdk15classifier> 
    dependency> 
  <dependencies>

Maven依赖配置最佳实践

自动化的依赖引用很容易造成依赖重复，进而造成冲突。为了优化Maven依赖，我们需要了解Maven对重复依赖的调解的两个原则：

1. 路径最近优先
2. 第一声明者优先

常用技巧：

• 排除依赖
  参考上文中对excludions元素的描述
• 归类依赖
  使用Maven属性统一相同项目不同模块的依赖版本

    <properties>
        <springframework.version>2.5.6springframework.version>
    properties>
    <dependencies>
        <dependency>
            <groupId>org.springframeworkgroupId>
            <artifactId>spring-coreartifactId>
            <version>${springframework.version}version>
        dependency>
        <dependency>
            <groupId>org.springframeworkgroupId>
            <artifactId>spring-beansartifactId>
            <version>${springframework.version}version>
        dependency>
        <dependency>
            <groupId>org.springframeworkgroupId>
            <artifactId>spring-contextartifactId>
            <version>${springframework.version}version>
        dependency>
        <dependency>
            <groupId>org.springframeworkgroupId>
            <artifactId>spring-context-supportartifactId>
            <version>${springframework.version}version>
        dependency>
    dependencies>

• 优化依赖
  可以使用如下命令分析依赖树，并优化依赖树
  mvn dependency:list
mvn dependency:tree
mvn dependency:analyze
  重点关注声明未使用和使用未声明的依赖，并进行修改