Maven实战（一）—— 依赖

阅读更多

依赖配置：

例如：

  ...


      group-a
      artifact-a
      1.0


          group-c
          excluded-artifact




      group-a
      artifact-b
      1.0
      bar
      runtime

 

依赖会包含基本的groupId, artifactId,version等元素，根元素project下的dependencies可以包含一个或者多个dependency元素，以声明一个或者多个依赖。每个依赖可以包含的元素：

 groupId、artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。 

 type：依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值是jar。

 scope：依赖的范围，下面会进行详解。 

 optional：标记依赖是否可选。 

 exclusions：用来排除传递性依赖。     

 

依赖传递：

依赖是会被传递的，例如：A-->C B-->A ==>B-->C（这种依赖是基于compile这个范围进行传递），

在dependency配置中如果没有写scope默认就是compile范围，依赖的传递主要是针对compile作用域。

 

依赖范围：

      compile：编译范围。默认的依赖范围，指的是编译范围有效，在编译和打包时都会将依赖存储进去；

      provided：可提供范围。范围指的是在编译和测试的过程有效，最后生成war包时不会加入，诸如：servlet-api，因为servlet-api,tomcat等web服务器已经存在了，如果再打包会冲突；

      test：测试范围。范围指的是测试范围有效，在编译和打包时都不会使用这个依赖；

      runtime：运行时范围。在运行的时候依赖，在编译的时候不依赖。

      system：系统范围。与provided 类似，但是你必须显式的提供一个对于本地系统中JAR 文件的路径，同时提供一个 systemPath 元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。

 

依赖冲突：

     1、如果a依赖于b的1.0版本，c依赖于b的1.1版本，d依赖于a和c，这时在d的pom中哪一个依赖先写就使用先写依赖的版本。

     2、如果a依赖于b的1.0版本，c依赖于b的1.1版本，d依赖于a和c，f依赖于d和c，依赖的路径的长短不一致就选择最小的。

     3、如果希望精确的控制依赖包，可以使用依赖的排除功能——> exclusions来排除。

 

可选依赖：

       有时候我们不想让依赖传递，那么可配置该依赖为可选依赖，将元素optional设置为true即可，例如：

  commons-logging 

  commons-logging 

  1.1.1 

  true

那么依赖该项目的其他项目将不会得到此依赖的传递。

 

依赖排除：

       当我们引入第三方jar包的时候，难免会引入传递性依赖，有些时候这是好事，然而有些时候我们不需要其中的一些传递性依赖，比如上例中的项目，我们不想引入传递性依赖commons-logging，我们可以使用exclusions元素声明排除依赖，exclusions可以包含一个或者多个exclusion子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明exclusions的时候只需要groupId和artifactId，而不需要version元素，这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说，Maven解析后的依赖中，不可能出现groupId和artifactId相同，但是version不同的两个依赖。 如下是一个排除依赖的例子：

     org.springframework

     spring-core

     2.5.6

     

           

                commons-logging  

                commons-logging