Maven依赖的配置

一.依赖的配置

<project>
	<dependencies>
		<groupid></groupid>
		<artifactId></artifactId>
		<version></version>
		<type></type>
		<scope></scope>
		<optional></optional>
		<exclusions>
			<exclusion>
			</exclusion>
		</exclusions>
	</dependencies>
</project>

groupId、artifactId、version:依赖的基本坐标，Maven根据坐标才能找到需要的依赖。

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

scope：依赖的范围。

optional：标记依赖是否可选。

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

注：大部分依赖声明只包含基本坐标，然而在一些特殊情况下，其他元素至关重要。

二.依赖范围

依赖范围就是用来控制依赖与这三种classpath（编译：classpath、测试：classpath、运行：classpath）的关系。

Maven依赖范围：

compile:编译依赖范围。如果没有指定，就会默认使用该依赖范围，使用此依赖范围的Maven依赖，

对于编译、测试、运行三种classpath都有效。典型的例子是：spring-core，在编译、测试和运行的时候都需要使用此依赖。

test：测试依赖范围。使用此依赖范围的Maven环境，只对于测试classpath有效，在编译主代码或者运行项目的时候将无法使用此类依赖。

典型的例子是JUnit,它只有在编译测试代码及运行测试的时候才使用。

provided:以提供依赖范围。使用依赖范围的Mavne依赖，对于编译和测试class-path有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候

需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入。

runtime：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行class-path有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译

只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。

system：系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件

的路径。由于此类依赖不是通过Mavne仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

import：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。

三:传递性依赖

什么是传递性依赖?

    传递性依赖就是一个项目需要依赖其它项目来完成功能，例如在开发中我们会使用spring项目，我们就会手动添加spring的jar包，这就是一种依赖，而spring又可能去依赖其它项目jar包，这就形成了一种传递性。（纯属个人见解），缺点：手动往往会添加一些不必要的jar包。

用Maven来管理项目时，Maven会解析各个直接依赖的POM,将那些必要的间接依赖，以传递性依赖的形式引入到当前项目中。

四：传递性依赖和依赖范围的关系

    依赖范围不仅可以控制依赖与三种classpath的关系，还对传递性依赖产生影响。

    假设：A依赖与B，B依赖与C，我们说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。，第一直接依赖的范围和第二直接依赖的范围决定了

传递性依赖的范围。