Maven 中直接依赖怎样影响间接依赖

相信学 Maven 的都看过 Maven 的官网文档的 Introduction to Dependency Mechanism。在介绍直接依赖怎样影响间接依赖时，它给出了一个表格：

	compile	provided	runtime	test
compile	compile	-	runtime	-
provided	provided	provided	provided	-
runtime	runtime	-	runtime	_
test	test	-	test	-

表格的最左边的列是直接依赖的名字，最上面的行是间接依赖的名字。“-”表示依赖将被忽略，也就是没有依赖。比如 project-a 对 project-b 有 compile 依赖，project-b 对 project-c 有 runtime 依赖，那么根据表格 project-a 对 project-c 有 runtime 依赖。

我看这个表格时的第一反应是，依赖不是越变越强吗？怎么 compile 对上 runtime 变成 runtime 了？不应该是 compile 吗？仔细想想，如果 project-a 在编译期依赖 project-b，project-b 只是在运行期需要 project-c，那么 project-a 的确只是在运行期需要 project-c，编译时用不到它。相似地，表格中的每一种情况都能举出类似的例子。也就是，当 project-1 依赖 project-2，project-2 依赖 project-3……，最终，project-1 间接依赖了 project-n 的时候，project-1 对 project-n 的依赖性基本取决于依赖链中最弱的一环。为什么说是基本上呢？因为很多情况下依赖链走到某一步时就断了，依赖被忽略了，也就是说没有依赖了。比如 runtime 遇上 provided 就断了。

这么看这个表格就清晰了，每个单元格都对应行列中最弱的那个，甚至是“-”。在那什么情况下会出现“-”呢？test 列对应的单元格全部是“-”。因为如果 project-b只是在测试的时候需要 project-c，那么说明 project-a 根本就不需要依赖 project-c。比如你的项目依赖 Spring，而 Spring 在测试期几乎毫无悬念地会依赖 JUnit。你的项目肯定不会把 JUnit 作为依赖的。相似地，provided 列对应的单元格也基本上都是“-”。Provided-provided 有什么特殊的地方呢？如果 project-webapp 依赖 web server 的某个 jar，这个 jar 又依赖 servlet-api.jar，你的 project-webapp 就对 servlet-api.jar 有 provided 依赖。这个例子很牵强，不过很合情合理，对不对？从依赖管理的角度看，provided 依赖实在是太弱了，我觉得跟没有依赖也差不多了。

个人推荐一本书《Maven: The Definitive Guide》。浏览过官网的几个 introductions 之后再看此书速度奇快。官网文档不推荐太过仔细地看，毕竟 Apache 文档糟糕已经不是一天两天了~~~