第五章：坐标和依赖

1.每个依赖中可以包含的元素有：

• groupId，artifactId，version: 这三个元素是Maven项目最重要的元素。Maven需要根据这三个坐标找到需要的依赖。
• type:依赖的类型，对应所依赖的项目所定义的packaging。一般此元素不必声明，默认为jar
• scope：依赖范围，后面会详细讲解
• optional:标记依赖是否可选
• exclusions:用来排除依赖性传递

2.依赖范围：

需要知道的是：Maven在编译，测试，运行使用的是不同的classpath（编译classpath，测试classpath，运行classpath）

注：这里的classpath和J2EE中的WEB-INI的classpath不是同一个概念。此处的classpath是javac命令编译的时候，-classpath参数

依赖范围是用来控制Maven项目所引入的依赖于这三种classpath的关系。

Maven有一下集中依赖范围：

• compile（默认）:编译依赖范围。此范围对于编译、测试、运行三种classpath都有效
• test:测试依赖范围。此范围只对于测试classpath有效，典型的例子：JUnit
• provided:已提供依赖范围。此范围对于编译、测试两种classpath有效,典型例子api  (注：第一次看到此范围，一直不明白为什么叫provided范围，后来再次看，理解到有时候项目是在一个容器里面运行的，而这个容器已经提供了项目运行所需要的api。比如：Servlet、jre和jdk的区别一样provided:已提供范围全称应该叫运行时api已经提供的范围。)
• runtime:运行时依赖。此范围对于测试、运行classpath有效，编译的时候无效。典型例子：JDBC (注：为什么runtime不只是对运行时有效？)
• system（尽量别用）:系统范围依赖。此范围对于编译、测试两种classpath有效。与provided区别：使用system依赖必须通过systemPath元素显式指定依赖文件的路径,由于路径一般是与本机系统绑定的，可能对系统移植带来一定的问题，因此谨慎使用

   <dependency>

        <groupId>junit</groupId>

        <artifactId>junit</artifactId>

        <version>4.7</version>

        <scope>system</scope>

        <systemPath>${java.home}/lib/rt.jir</systemPath>

    </dependency>

• import：导入依赖范围，该依赖范围不会对classpath产生实际影响。后续详细介绍。

3.依赖传递

传统不使用Maven的项目中，往往需要手动的下载相关依赖，但是由于依赖可能又会依赖其他的类库，层层引入，因此可能会引入很多其他的不必要的依赖。

或者是之引入一个简单的依赖，这个依赖不包含其他的依赖，然后根据出错的信息，依次引入其他的依赖，这种方法，更加麻烦。

Maven传递性依赖机制可以很好的解决这一个问题。

看例子：

account-email 引入了一个org.springframework:spring-core:2.5.6依赖，同时spring-core包含了一个commons-logging依赖，对于commons-logging依赖，默认使用的依赖范围为compile，同时对于spring-core，account-email声明的依赖也是compile。

那么commons-logging便成为account-email的传递依赖。

传递依赖和依赖范围：

(最左边一列表示第一依赖范围，最上边一行表示第二依赖范围)

想一想为什么要这样设计？