具有提供范围的Maven传递依赖项
根据Maven完整参考中的图像，当直接依赖关系范围为“编译”并且传递依赖关系的范围为“提供”时，传递依赖关系将被忽略。
我的问题是，如果直接依赖类从我的项目的传递依赖编译中扩展一个类将失败，因为在编译时'javac'将从传递依赖中寻找由直接依赖扩展的类，并且不会在编译时类路径中找到它，因为maven忽略了它。
基本上这就是编译直接依赖时编译传递依赖范围而不是运行时的原因，为什么提供传递依赖范围时不考虑相同的规则？
共有1个答案
>
compile需要是可传递的，您的继承示例就是其中一个原因。当然，您通常不需要所有可传递的编译依赖项来进行编译，但安全性比抱歉要好。
提供的是不可传递的。我的解释如下：提供意味着容器/平台为您提供所需的工件。提供的内容和不提供的内容取决于容器。如果不知道库的依赖项将在哪个容器上运行，那么将库的依赖项标记为提供的是没有意义的。因此，根据“可部署单元”的级别对依赖项进行“排序”更有意义，例如战争或ear。
-
理想情况下，在我的maven项目中，我只需要https://gist.github.com/kameshsampath/8a4bdc8b22d85bbe3f243fa1b816e464#file-src_main_build-l8-l9，尽管generate_workspace.bzl已经正确地解决了问题，如果我的src/main/build看起来像 但遗憾的是，这会导致大量编译错误，因为传递性D
-
在为android项目添加新的依赖项时，特别是在中，在中，有三个作用域选项compile/provide/apk。
-
我已经将maven依赖项的范围更改为提供并手动复制到tomcat/lib（以减小war文件的大小）。 在我的启动脚本中设置CATALINA_OPTS可以解决这个问题，为什么？
-
我的情况： 我有两个独立的项目A和B。 没有项目A。 A和B使用相同的库： < li >反射-0.9.9-RC1.jar < li >番石榴-11.0.2.jar < Li > XML-API-1.0 . B2 . jar < li>javassist-3.16.1-GA.jar < li>dom4j-1.6.1.jar < li>jsr305-1.3.9.jar 我制作了项目C，这是项目a的插件
-
主要内容：依赖传递,依赖范围,依赖范围对传递依赖的影响,依赖调节Maven 依赖传递是 Maven 的核心机制之一，它能够一定程度上简化 Maven 的依赖配置。本节我们将详细介绍依赖传递及其相关概念。 依赖传递 如下图所示，项目 A 依赖于项目 B，B 又依赖于项目 C，此时 B 是 A 的直接依赖，C 是 A 的间接依赖。 Maven 的依赖传递机制是指：不管 Maven 项目存在多少间接依赖，POM 中都只需要定义其直接依赖，不必定义任何间接依赖，Mav
-
我给ivy添加了一个依赖项（我们称之为a）。在maven central中具有pom文件的xml。Ivy使用ibiblio来解析maven依赖项。添加到常春藤中的依赖项（A）。xml具有可传递依赖项（B）。到目前为止，一切都很好。传递依赖（B）的依赖（C）不能用常春藤来解决。 我在常春藤上定义了一个新的名字。如下所示的xml： 在B的pom文件中，C在编译和测试范围中定义如下： 当我在ivy的缓存