Maven依赖作用范围

依赖管理

1. 依赖配置

在maven中，是在pom.xml文件中完成依赖的配置的，我们先来看看依赖配置的语法。

乍一看，这个配置还是蛮复杂的，其实我们常用的没有这么多，而且这些用起来也是非常简单的。在pom.xml文件中，根元素project下的dependencies标签中可以包含一个或者多个dependency元素，以声明一个或者多个项目依赖。每个依赖dependency标签中都应该包含以下元素：
1、groupId：可以理解为一个java的包名（名称默认以公司域名倒写），在对应的本地仓库中，它是一个可以有很多层的目录，并且以.来进行目录分级。
2、artifactId：可以理解成项目或者模块的名称
3、version：表示项目或者模块的版本
4、type：依赖的类型，对应于项目坐标定义的Packaging，大部分情况下，该元素不必声明，其默认值为jar
5、scope：依赖的范围，重点
6、optional：标记依赖是否可选
7、exclusions：用来排除传递性依赖。其中可配置多个exclusion标签，每个exclusion标签里面对应的有groupId、artifactId、version三项基本元素

很多时候，大部分依赖声明只包含groupId、artifactId和version这三个指定基本坐标的元素；而在一些特殊情况下，其它元素至关重要，也就是上面提到的scope、optional和exclusions。

2. 依赖范围

依赖范围是什么？
我们需要知道，maven在编译项目主代码的时候需要使用一套classpath。举例来说：

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

依赖范围具体有哪些？
scope（依赖范围）共有五种，它们分别是compile、provided、runtime、test、system。

• compile
  编译依赖范围。如果没有指定scope值，那么就会默认使用该依赖。使用该依赖范围的maven依赖，对于编译、测试、运行这三种classpath都有效。
• provided
  已提供依赖范围。使用此依赖范围的maven依赖，对于编译和测试classpath有效，但在运行时无效。最典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于tomcat容器已经提供，所以就不需要maven重复地引入一遍了。
• runtime
  运行时依赖范围。使用此依赖范围的maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。最典型的例子就是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
• test
  测试依赖范围。使用此依赖范围的maven依赖，只对于测试classpath有效，在编译主代码或者运行项目时都无法使用此依赖。最典型的例子就是JUnit，它只有在编译测试代码及运行测试用例的时候才需要。也就是说，在编译和测试时是需要的，但在运行时不需要，因为在测试的时候，我们是用来跑测试用例的，而将来把项目打成jar包或者war包，丢到服务器上去，还要跑测试用例吗？肯定是不需要的。
• system
  系统依赖范围。该依赖与三种classpath的关系和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此谨慎使用。system的使用例子如下：
  

总结

为了更好的理解和记忆依赖范围与classpath的关系，可以将上述内容总结成一张表格。