在Transitive Scope Table中，根据每个范围的定义，大多数似乎是合理的：编译，提供，运行时，测试。除了两种组合，我完全被结果搞糊涂了。两者都在Transitive Scope Table的运行时列下，一列用于提供的行，一列用于测试行。
假设A在范围测试下依赖于B，并且B在范围运行时依赖于C，这意味着B应该在测试类路径中编译A或运行A的单元测试，而C应该在测试类路径中运行B的单元测试;所以根据我的理解，C应该只出现在测试类路径中才能运行A的单元测试，但是不需要出现在测试类路径中来编译A，所以看起来结果应该是“在范围运行时依赖于C，而不是测试”
类似地，如果A在提供的范围内依赖于B，并且B依赖于范围运行时的C，则意味着B应该在测试类路径中编译A，而B应该由JDK或容器提供以运行A的单元测试，并且C应该在测试类路径中运行B的单元测试;所以根据我的理解，C应该在测试类路径中运行A的单元测试，无论C是由JDK提供还是容器，或者在测试类路径中显式提供，但是不需要出现在测试类路径中来编译A，因此结果可能是运行时（尽管运行时无法指示JDK或容器提供的含义，但我找不到其他更合理的范围），但未提供。
也许我想念一些我不知道的重要知识。我是Maven的新手，所以任何人都知道为什么文件说结果应该提供并测试？
答案 0 :(得分：1)
假设A在范围测试下依赖于B，并且B在范围运行时依赖于C，这意味着B应该在测试类路径中编译A或运行A的单元测试，而C应该在测试类路径中运行B的单元测试;所以根据我的理解，C应该只出现在测试类路径中以运行A的单元测试，但是不需要出现在测试类路径中来编译A，所以看起来结果应该是＆＃34; A依赖于范围运行时的C，不测试＆＃34;。
B的范围为test，C的范围为test * runtime = test。
类似地，如果A在提供的范围内依赖于B，并且B依赖于范围运行时的C，则意味着B应该在测试类路径中编译A，
作为provided，B在编译和测试类路径中。
和B应由JDK或容器提供，以运行A的单元测试，而C应在测试类路径中运行B的单元测试;
如果我们说A，运行B的测试是无关紧要的。但是如果环境提供B，那么它也应该提供B的运行时依赖性，因此C。
所以根据我的理解，C应该在测试类路径中运行A的单元测试，不管C是由JDK或容器提供的，还是在测试类路径中显式可用，而不需要出现在测试类路径中来编译A，因此结果可能是运行时（虽然运行时无法指示JDK或容器提供的含义，但我找不到其他更合理的范围），但未提供。
你基本上想知道为什么provided * runtime = provided。从技术上讲，我认为你是对的，runtime范围就足够了。问题是语义。 provided表示它由容器提供，因此如果C是提供的依赖项B的运行时依赖项，则它也由容器提供。 provided更好地表达了这一点。
实际上，典型的provided依赖项通常不具有某些runtime依赖项。 provided依赖项通常是某种API，runtime依赖项通常是实现。因此，对runtime依赖性具有provided依赖性基本上会削弱分离API和实现的整个想法。那么为什么首先要有两个工件呢？