为什么测试范围依赖关系会在Maven中拉取编译范围依赖关系？
目前我的项目使用Spring启动测试如下：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<version>2.3.8.RELEASE</version>
<scope>test</scope>
</dependency>
但是，尽管有测试范围，它还是引入了sping-core（这是此版本中易受攻击的tpl）作为编译范围传递依赖项，并且它出现在我编译的二进制文件中。
我知道我可以通过使用测试范围显式拉动Spring核心来解决这个问题：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.2.12.RELEASE</version>
<scope>test</scope>
</dependency>
然而，这不应该是必要的。为什么只有在将依赖项拉入编译范围的测试中才有依赖项？
共有1个答案
在J FabianMeyer的评论之后，我仔细检查了一下。当spring核心出现在依赖树中的spring boot starter测试下时，spring boot starter web将其拉入编译范围。
我的猜测是sping-boot-starter-test拉动了sping-core的更高版本，这就是它出现在树中的原因
-
我想知道为什么我的简单spring boot项目不再有效。它基本上直接来自spring示例，其中一个控制器说hello world。我使用的是spring boot starter jetty和spring boot v1.1.10（也尝试了1.2.0）。我有一些使用嵌入式solr的单元测试，所以solr核心被标记为<代码> 我认为测试范围的依赖关系不应该干扰编译范围的依赖关系，并且“仅适用于测试
-
理想情况下，在我的maven项目中，我只需要https://gist.github.com/kameshsampath/8a4bdc8b22d85bbe3f243fa1b816e464#file-src_main_build-l8-l9，尽管generate_workspace.bzl已经正确地解决了问题，如果我的src/main/build看起来像 但遗憾的是，这会导致大量编译错误，因为传递性D
-
问题内容： 我有一个依赖关系如下： 当我部署一切正常时，这将拉下另一个引发ClassDefNotFound的依赖项。 我添加了两个依赖项，如下所示： 并且仍然面临着同样的问题，即：MVN带来下来不 我该如何解决？ 编辑： 添加; 问题答案： 您可能有一个传递依赖项，另一个依赖项取决于您不需要的版本。 要获得所有直接和传递依赖关系的概述，请尝试： mvn依赖项：树 如果您发现同一依赖项的不同版本之间
-
问题内容： 我在ivaven.xml中添加了一个依赖项（让我们将其命名为A），它在maven Central中具有一个pom文件。Ivy使用ibiblio解决了Maven依赖关系。添加到ivy.xml的依赖项（A）具有传递的依赖项（B）。到目前为止，到目前为止很好。常春藤无法解决传递性依赖项（B）的依赖项（C）。 我在ivy.xml中定义了A，如下所示： 在B的pom文件中，在编译和测试范围中都定
-
41.1 测试范围内的依赖 如果使用了spring-boot-starter-test“启动器”（scope为test），将得到以下库： JUnit —— Java程序单元测试事实上的标准 Spring Test & Spring Boot Test —— 工具类以及支持Spring Boot程序的集成测试 AssertJ —— 一个优美的断言库 http://hamcrest.org/JavaH
-
我试图从命令行显示我正在使用maven dependency插件版本3.1.2开发的项目的完整依赖关系树，但是目标（以及maven dependency插件中的任何其他目标）没有显示依赖关系。插件的文档(https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html)声明默认情况下包含所有作用域，因此不需要使用-Dsc