compile（编译范围）
默认就是 compile，什么都不配置也就是意味着 compile。compile 表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。
test（测试范围）
表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。比较典型的如 junit。
runntime（运行时范围）
表示被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。与 compile 相比，跳过编译 而已，
说实话在终端的项目（非开源，企业内部系统）中，和 compile 区别不是很大。比较常见的如 JSR×××的实现，对应的 API jar 是 compile 的，
具体实现是 runtime 的，compile 只需要知道接口就足够了。Oracle jdbc 驱动架包就是一个很好的例子，一般 scope 为 runntime。
另外 runntime 的依赖通常和 optional 搭配使用，optional 为 true。我可以用 A 实现，也可以用 B 实现。
provided（已提供范围）
表示打包的时候可以不用包进去，别的设施 (Web Container) 会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于 compile，但是在打包阶段做了 exclude 的动作。
例如一个 web 应用，可能在编译 classpath 中需要可用的 Servlet API 来编译一个 servlet，但是不会在打包好的 WAR 中包含这个 Servlet API；
这个 Servlet API JAR 由应用服务器或者 servlet 容器提供。已提供范围的依赖在编译 classpath（不是运行时）可用。它们不是传递性的，也不会被打包。
system（系统范围）
system 范围依赖与 provided 类似，但是必须显式的提供一个对于本地系统中 JAR 文件的路径。这么做是为了允许基于本地对象编译，
而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。如果将一个依赖范围设置成系统范围，必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的（应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。
依赖传递
A–>B–>C
当前项目为 A，A 依赖于 B，B 依赖于 C，当 C 的 Scope 是 test 或者 provided 时，C 直接被丢弃，A 不依赖 C；
否则 A 依赖 C，C 的 Scope 继承于 B 的 Scope。