04-依赖详解

最简单的依赖

<dependency>  
  <groupId>junit</groupId>  
  <artifactId>junit</artifactId>  
  <version>4.4</version>  
</dependency> 

依赖是使用Maven坐标来定位的，而Maven坐标主要由GAV（groupId, artifactId, version）构成。因此，使用任何一个依赖之间，你都需要知道它的Maven坐标。关于如何确定坐标。将在后面讲解。上例中我们声明了一个对junit的依赖，它的groupId是junit, artifactId是junit, version是4.4。这一组GAV构成了一个Maven坐标，基于此，Maven就能在本地或者远程仓库中找到对应的junit-4.4.jar文件。

依赖范围(scope)

对于Junit，一般来说你只有在运行测试的时候需要它，也就是说，它对于src/main/java的classpath没什么意义，并且，将Junit的jar文件打入最终的发布包也不是好事，这无谓的增加了发布包的大小。其实我们应该这样做：

<dependency>  
  <groupId>junit</groupId>  
  <artifactId>junit</artifactId>  
  <version>4.4</version>  
  <scope>test</scope>  
</dependency> 

于是，junit对于主源码classpath不可用，对于测试源码classpath可用，不会被打包。再举个例子，在开发javaee应用的时候我们一定会用到servlet-api，它对于主源码和测试源码都是必要的，因为我们的代码中会引入servlet-api的包。但是，在打包的时候，将其放入WAR包就会有问题，因为web容器会提供servlet-api，如果我们再将其打包就会造成依赖冲突，解决方案如下：

<dependency>  
  <groupId>javax.servlet</groupId>  
  <artifactId>servlet-api</artifactId>  
  <version>2.4</version>  
  <scope>provided</scope>  
</dependency> 

主要的依赖范围以及作用：

compile：编译依赖范围（默认），使用此依赖范围对于编译、测试、运行三种 classpath 都有效，即在编译、测试和运行的时候都要使用该依赖jar包；

test：测试依赖范围，从字面意思就可以知道此依赖范围只能用于测试classpath，而在编译和运行项目时无法使用此类依赖，典型的是JUnit，它只用于编译测试代码和运行测试代码的时候才需要；

provided：此依赖范围，对于编译和测试classpath有效，而对运行时无效；

runtime：运行时依赖范围，对于测试和运行classpath有效，但是在编译主代码时无效，典型的就是JDBC驱动实现；

system：系统依赖范围，使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件的路径，不依赖Maven仓库解析，所以可能会造成建构的不可移植，谨慎使用。

import：导入依赖范围。

依赖范围（scope）	主源码classpath可用（compile）	测试源码classpath可用（test）	运行源码classpath可用（runtime）	会被打包
compile 缺省值	TRUE	TRUE	TRUE	TRUE
test	FALSE	TRUE	FALSE	FALSE
runtime	FALSE	TRUE	TRUE	TRUE
provided	TRUE	TRUE	FALSE	FALSE

依赖管理（dependencyManagement）

1. 在父模块中使用dependencyManagement配置依赖
2. 在子模块中使用dependencies添加依赖

dependencyManagement实际上不会真正引入任何依赖，dependencies才会。但是，当父模块中配置了某个依赖之后，子模块只需使用简单groupId和artifactId（这样在依赖的地方就可以不使用version等）就能自动继承相应的父模块依赖配置。例如：

父模块中如此声明：

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.sonatype.mavenbook</groupId>
    <artifactId>a-parent</artifactId>
    <version>1.0.0</version>
    ...
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>mysql</groupId>
                <artifactId>mysql-connector-java</artifactId>
                <version>5.1.2</version>
            </dependency>
            ...
            <dependencies>
    </dependencyManagement>  
 </project>

子模块中如此声明：

<project>  
  <modelVersion>4.0.0</modelVersion>  
  <parent>  
    <groupId>org.sonatype.mavenbook</groupId>  
    <artifactId>a-parent</artifactId>  
    <version>1.0.0</version>  
  </parent>  
  <artifactId>project-a</artifactId>  
  ...  
  <dependencies>  
    <dependency>  
      <groupId>mysql</groupId>  
      <artifactId>mysql-connector-java</artifactId>  
    </dependency>  
  </dependencies>  
</project>

可以看到子模块中没有添加依赖的版本，此时直接使用了父模块的版本。你依赖配置越复杂，依赖管理所起到的作用就越大，它不仅能够帮助你简化配置，它还能够帮你巩固依赖配置，也就是说，在整个项目中，对于某个构件（如mysql）的依赖配置只有一种，这样就能避免引入不同版本的依赖，避免依赖冲突。

聚合

为了能够使用一条命令就能构建 account-email和 account-persist两个模块，我们需要建立一个额外的名为 account-aggregator的模块，然后通过该模块构建整个项目的所有模块。 account-aggregator本身也是个 Maven项目，它的 POM如下：

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.juvenxu.mvnbook.account</groupId>
    <artifactId>account-aggregator</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <!-- packaging的类型必须为pom -->
    <packaging> pom </packaging>
    <name>Account Aggregator</name>
    <modules>
        <!-- module的值是一个以当前POM为主目录的相对路径。如：../artifactId -->
        <module>account-email</module>
        <module>account-persist</module>
    </modules>
</project>

继承

可声明父POM供子 POM继承，父模块POM如下：

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.juvenxu.mvnbook.account</groupId>
    <artifactId> account-parent </artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <!-- packaging的类型必须为pom -->
    <packaging>pom</packaging>
    <name>Account Parent</name>
</project>

子模块声明继承如下：

<project>
    <modelVersion>4.0.0</modelVersion>
 
    <parent>
        <groupId>com.juvenxu.mvnbook.account</groupId>
        <artifactId> account-parent </artifactId>
        <version>1.0.0-SNAPSHOT</version>
        <!-- 当父模块发布到私服后，此配置可不用写,注意pom文件的相对路径 -->
        <relativePath>../account-parent/pom.xml</relativePath>
    </parent>
 
    <artifactId> account-email </artifactId>
    <name>Account Email</name>
    ...
</project>

子模块没有声明groupId和version, 这两个属性继承至父模块。但如果子模块有不同于父模块的 groupId、version ，也可指定；