04-依赖详解

最简单的依赖

  
  junit  
  junit  
  4.4  
 

依赖是使用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文件打入最终的发布包也不是好事，这无谓的增加了发布包的大小。其实我们应该这样做：

  
  junit  
  junit  
  4.4  
  test  
 

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

  
  javax.servlet  
  servlet-api  
  2.4  
  provided  
 

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

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等）就能自动继承相应的父模块依赖配置。例如：

父模块中如此声明：

    4.0.0
    org.sonatype.mavenbook
    a-parent
    1.0.0
    ...
    
        
            
                mysql
                mysql-connector-java
                5.1.2
            
            ...
            
      
 

子模块中如此声明：

  
  4.0.0  
    
    org.sonatype.mavenbook  
    a-parent  
    1.0.0  
    
  project-a  
  ...  
    
      
      mysql  
      mysql-connector-java  
      
    

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

聚合

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

    4.0.0
    com.juvenxu.mvnbook.account
    account-aggregator
    1.0.0-SNAPSHOT
    
     pom 
    Account Aggregator
    
        
        account-email
        account-persist
    

继承

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

    4.0.0
    com.juvenxu.mvnbook.account
     account-parent 
    1.0.0-SNAPSHOT
    
    pom
    Account Parent

子模块声明继承如下：

    4.0.0
 
    
        com.juvenxu.mvnbook.account
         account-parent 
        1.0.0-SNAPSHOT
        
        ../account-parent/pom.xml
    
 
     account-email 
    Account Email
    ...

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