(十)maven核心概念-依赖范围

不知道你是否发现Junit的依赖跟别的有些区别，什么？没有发现？那你观察的不够仔细啊。让我们来看一下在前面的教程中出现的Junit的依赖和apach-common依赖的声明。
Junit：
 <dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
 
apace-common：
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>


 
 
发现区别了吗？在Junit的依赖声明中多出了一个scope标签<scope>test</scope>，那么这个是干什么用的呢。这个就是依赖范围，依赖范围通常用来限制依赖的传递，同时也会影响到用于各种构建任务的类路径，说的太晦涩了，这不是我说的，这是maven官方文档说的O(∩_∩)O~，下面我们来详细看一下。
maven在编译代码的时候需要使用一套classpath、在编译和执行测试的时候会使用另一套classpath、运行的时候又会使用一套classpath。依赖范围就是用来控制依赖与这三种classpath的关系，maven有6中可用的依赖范围：
compile    默认的范围；如果不指定范围，那该依赖的范围就是编译范围。编译范围依赖在所有的classpath 中可用，同时它们也会被打包。
provided    这个比较像compile范围，只有在当JDK 或者一个容器已提供该依赖之后才使用，比如，当你构建一个J2EE项目时，你可以将Servlet API和相关Java EE API的依赖范围声明为 provided，因为web容器（如tomcat）已经提供了这些类。
runtime    依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API jar，而只有在运行的时候才需要JDBC
test    在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。
system   system范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统中JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。
import   （仅在Maven2.0.9或更高版本可用）导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。
 
注：依赖范围只要知晓即可，在实际工作中用到的不是很多，可以在使用到的时候在回来查也来得及。
 
 
参考：https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

原文地址：http://ittechcourse.com/archives/70