Scope的分类
- compile
默认的scope，表示 dependency 都可以在生命周期中使用。而且，这些dependencies 会传递到依赖的项目中。适用于所有阶段，会随着项目一起发布。即依赖的项目会参与到当前项目的编译、运行、测试以及打包发布，是一个比较强的依赖范围。 - test
表示dependency作用在测试时，不作用在运行时。 只在测试时使用，用于编译和运行测试代码。不会随项目发布。 - runntime
表示dependency不作用在编译时，但会作用在运行和测试时，如JDBC驱动，适用运行和测试阶段。即是跳过编译阶段，只参与测试或运行。 - provided
跟compile相似，但是表明了dependency 由JDK或者容器提供，例如Servlet AP和一些Java EE APIs。这个scope 只能作用在编译和测试时，同时没有传递性。
即该依赖是由系统组件提供的，我们不需要手动添加，它只存在于编译、运行和测试阶段，打包的时候并不会打进去，被剔除了的。 - system
跟provided 相似，但是在系统中要以外部JAR包的形式提供，maven不会在repository查找它。需通过外部引入，不会在仓库中查找。例如一些特殊的jar我们或通过拷贝jar到web-info/lib下，这些jar就可以配置为system范围。
这里表述只是基于maven环境，有些同学在IDE(eclipse)下实践，由于IDE提供一些辅助功能，与上述记述不是十分符合。
依赖传递
如有三个项目A、B、C，当前项目为A，A依赖于B，B依赖于C。则项目C在A中是什么样的依赖关系呢？
我们可以根据B依赖于C的scope来判断：
- scope为test、provided、system时，则项目C被抛弃，A并不依赖于C
- 否则A依赖于C
依赖隔断
由上所述，maven的依赖关系是有传递性的。如：A–>B，B–>C，则A–>C。但有时候，项目A可能不是必需依赖C，因此需要在项目A中隔断对C的依赖。隔断依赖有2种方式：
- 可选依赖（Optional Dependencies）
- 依赖排除（Dependency Exclusions）
可选依赖
配置optional选项，待选值为true/false。默认为false，此时依赖关系为强依赖。
<project>
...
<dependencies>
<!-- declare the dependency to be set as optional -->
<dependency>
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional> <!-- value will be true or false only -->
</dependency>
</dependencies>
</project>这段配置为项目B依赖于项目C的配置，由于配置了optional为true，则项目A就被隔断了与项目C的依赖关系。如果想依赖C，则需要在项目A中另行配置。
依赖排除
依赖排除用标签exclusions，样例如下：
<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<!-- declare the exclusion here -->
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project> 此配置为项目A中的配置。当项目B依赖项目C时，并没有配置optional选项时，又不能更改项目B，则可以用此种方式隔断依赖关系。
依赖关系的隔断与scope中的provided都能阻止依赖关系的传递，个人认为他们之间的区别为
- scope中的provided：虽然工程上隔断了关系，但此时表明，被隔断的工程是需要其它地方提供支持的，在最终运行环境中应该是一定被用到的。一般情况上层工程里一定有调用此处接口的代码。
- 依赖关系的隔断则不一定如此，很有可能根本就不想用这个被排除的工程。
