maven scope 的作用

一：

1.Maven中的依赖作用范围概述

Maven中使用 scope 来指定当前包的依赖范围和依赖的传递性。常见的可选值有：compile, provided, runtime, test, system 等。scope 主要是用在 pom.xml 文件中的依赖定义部分，例如：

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-test</artifactId>
    <version>3.2.1.RELEASE</version>
    <scope>test</scope>
</dependency>

2.scope各种取值详解

scope取值	有效范围（compile, runtime, test）	依赖传递	例子
compile	all	是	spring-core
provided	compile, test	否	servlet-api
runtime	runtime, test	是	JDBC驱动
test	test	否	JUnit
system	compile, test	是

正如上表所示，

compile ：为默认的依赖有效范围。如果在定义依赖关系的时候，没有明确指定依赖有效范围的话，则默认采用该依赖有效范围。此种依赖，在编译、运行、测试时均有效。

provided ：在编译、测试时有效，但是在运行时无效。例如：servlet-api，运行项目时，容器已经提供，就不需要Maven重复地引入一遍了。

runtime ：在运行、测试时有效，但是在编译代码时无效。例如：JDBC驱动实现，项目代码编译只需要JDK提供的JDBC接口，只有在测试或运行项目时才需要实现上述接口的具体JDBC驱动。

test ：只在测试时有效，例如：JUnit。

system ：在编译、测试时有效，但是在运行时无效。和provided的区别是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。systemPath元素可以引用环境变量。例如：

<dependency>
    <groupId>javax.sql</groupId>
    <artifactId>jdbc-stdext</artifactId>
    <version>2.0</version>
    <scope>system</scope>
    <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>

二：

scope的分类
compile
默认就是compile，什么都不配置也就是意味着compile。compile表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。

test
scope为test表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。比较典型的如junit。

runntime
runntime表示被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。与compile相比，跳过编译而已，说实话在终端的项目（非开源，企业内部系统）中，和compile区别不是很大。比较常见的如JSR×××的实现，对应的API jar是compile的，具体实现是runtime的，compile只需要知道接口就足够了。oracle jdbc驱动架包就是一个很好的例子，一般scope为runntime。另外runntime的依赖通常和optional搭配使用，optional为true。我可以用A实现，也可以用B实现。

provided
provided意味着打包的时候可以不用包进去，别的设施(Web Container)会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是在打包阶段做了exclude的动作。

system
从参与度来说，也provided相同，不过被依赖项不会从maven仓库抓，而是从本地文件系统拿，一定需要配合systemPath属性使用。

scope的依赖传递
A–>B–>C。当前项目为A，A依赖于B，B依赖于C。知道B在A项目中的scope，那么怎么知道C在A中的scope呢？答案是： 
当C是test或者provided时，C直接被丢弃，A不依赖C； 
否则A依赖C，C的scope继承于B的scope。

三：

scope的值
1. compile 默认的范围，编译测试运行都有效。 
2. provided 编译和测试时有效，最后是在运行的时候不会被加入。官方举了一个例子。比如在JavaEE web项目中我们需要使用servlet的API，但是呢Tomcat中已经提供这个jar，我们在编译和测试的时候需要使用这个api，但是部署到tomcat的时候，如果还加入servlet构建就会产生冲突，这个时候就可以使用provided。 
3. runtime 在测试和运行时有效。 
4. test 在测试时有效。 
5. system 与本机系统相关联，可移植性差。编译和测试时有效。 
6. import 导入的范围，它只在使用dependencyManagement中，表示从其他pom中导入dependecy的配置。

四：Maven Scope provided 和 optional 的区别

它们的传递性是一样的，都不会传递。

唯一区别在于，例如 一个 war项目，provided的jar 不会被打进war包，而 optional 的jar 会打进war包。

从概念上、本质上来说：

provided的包是确实必须要的（如果第三方用到它，则需要第三方提供，如果没有，就会出错）

而optional的本意是，这个包是可选的（无论有没有，都不会出错）

最近参与了一个项目,使用maven管理依赖.项目拆分了很多模块.然后交个多个团队各自开发.最后在一个项目骨架中,把各自的模块引入进来,一起启动.

后来随着项目的深入.引入的jar包变多.发现

• jar包太多,编译太慢
• 打包之后的war包非常大

这种情况就可以使用optional来优化

什么是optional

optional是maven依赖jar时的一个选项,表示该依赖是可选的.不会被依赖传递

<optional>true</optional>

使用场景

以项目中使用到的日志框架为例.

例如

• B依赖了日志框架 logback、log4j、apache commons log
• 这时候的依赖关系如下 A->B

因为maven有依赖传递机制.那么A项目就会有3个jar包,logback、log4j、apache commons log.实际上我们一般只会在项目中使用一种日志框架.那么我们项目中就会有多余的依赖.当这种情况时越来越多时,最后整个项目的jar包就有很多的多余依赖,导致项目很臃肿.

如何优化

只要B项目中把logback、log4j、apache commons log设置成<optional>true</optional>

例如

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <optional>true</optional>
</dependency>

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <optional>true</optional>
</dependency>

这时候A项目依赖B的时候,项目中不会有logback、log4j、apache commons log jar包,可以根据情况自行选择一个即可.

总结

当你开发的组件时,有一个功能,有多种实现方式的jar可以提供,但是实际只会使用一种的情况下.可以把实现的jar包设置成<optional>true</optional>.表示: 瞧,你依赖我时,用到这个功能时,可以自行选择.而不是默认全部都给你.管你用不用.

为什么要使用optional

• 减少不必要的依赖传递
• 减少jar包冲突

原理

• 引入了optional实际上默认会做排除操作

It may be helpful to think of optional dependencies as "excluded by default