问题标签 [dependency-resolution]

Gradle 6.8 引入了在项目的不同阶段（如编译时间、运行时间、测试运行时间等）之间统一依赖关系解析的可能性，如docs中所示。

在编译时和运行时使用相同依赖项的想法似乎对我很有吸引力。尽管文档读到“一般来说，这（使用不同的依赖项取决于阶段）不是问题，但这也意味着您将在运行时使用的 Groovy（或其他）库的版本将与您用于编译的那个不同。”

所以我的问题是：激活一致的依赖解决方案是否值得，是否有人对这个功能有一定的经验？

我正在安装一个具有 Maven 依赖项的包，并在我尝试清理它时得到一个 DependencyResolutionException。克隆它后，我导航到目录并运行以下命令安装它，没有错误：

然后：

使用以下控制台输出：

如有必要，我可以发布调试日志开关的输出，但它很长。我也可以发布 pom.xml，但是据我所知，它会根据需要引用存储库。

我搜索过类似的帖子，但似乎没有一个包含相同系列的错误或类似的错误。有人可以帮我破译这些错误吗？

谢谢！

我在 CentOS 上使用 Maven 3.2.2 的项目中有以下内容：

使用示例中给出的顺序，dm-bom将正确找到 my ，但不是vaadin-bom. 如果我定义第vaadin-bom一个，那么问题就反过来了。

当项目定义多个导入的dependencyManagementpom 时，Maven 是否存在存储库定义问题？

Visual Studio 2019 提供了一个未公布的4.700.19.56404版本Microsoft.Bcl.AsyncInterfaces：

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Bcl.AsyncInterfaces

Autofac 接受此软件包的 1.1.0 或更高版本。但是，如果我尝试将 Microsoft.Bcl.AsyncInterfaces Nuget 包更新到最新版本 (5.0.0)，我会开始遇到包被解析为 4.700.19.56404 版本的问题，因为：

当然，在尝试运行时，由于Microsoft.Bcl.AsyncInterfaces无法加载而出现运行时错误。

我想最明显的问题是是否有办法通过 msbuild 解决这个问题，例如，某些目标可以在构建时将依赖关系解析为 5.0.0，而不是 4.700.19.56404。

否则，我认为这可以通过让 Autofac 将其Microsoft.Bcl.AsyncInterfaces依赖关系更新为 5.0.0 而不是 1.1.0 来解决。不确定这是否可行。

我正在使用 gradle 为 AsciidoctorJ 编写扩展。我的扩展适用于所有2.x.x版本的 AsciidoctorJ，所以我的想法是将依赖项声明为 range [2.0.0, 3.0.0[。

现在在 CI 系统上，我想使用多个版本的 AsciidoctorJ 进行测试，以确保它适用于该范围内的所有版本。

如果我使用锁定文件（请参阅锁定依赖版本，我不明白如何将版本设置为特定版本。--update-locks不要指望版本：

失败并出现此错误：

更新锁格式必须为<group>:<artifact>但'org.asciidoctor:asciidoctorj:2.2.0'无效。

这是预期的（如记录）。

我目前的解决方法是添加一个影响正在使用的严格版本的项目属性：

这按预期工作。我可以跑：

或者

我编写了一个 CI 作业，使用所有现有版本运行构建。

但是这个解决方案感觉很定制。我希望有更标准的东西并使用锁定文件。

而这样的例子不胜枚举....

有没有更好的方法来解决这种依赖关系，而不是像这样为每个服务编写代码。是否有任何其他方式，例如从程序集中读取或使用反射来解决这些依赖关系。这样，如果我有 300 个接口，我必须编写 300 行来解决依赖关系。

我正在使用 Kotlin 为 Unity 开发一个 Android 蓝牙插件。我包含了.aar我的 Kotlin 库文件（它在 Android Studio 中运行的应用程序中完美运行），由于我在运行时遇到了一些依赖错误，我开始使用Android Dependency Resolver 插件。

我首先添加了我的库在其.gradle文件中的依赖项：

按照 Dependency Resolver 的*Dependencies.xml指示，到我的图书馆：

Dependency Resolver 可以工作并且可以正常工作，但是当我尝试编译项目时出现错误：

目前我的项目使用spring boot starter test：

然而，尽管有测试范围，它还是将 spring-core（在此版本中是一个易受攻击的 tpl）作为编译范围传递依赖项引入，并且它出现在我编译的二进制文件中。

我知道我可以通过使用测试范围显式拉动弹簧芯来解决此问题：

然而，这不应该是必要的。为什么仅在测试中可用的依赖项将依赖项拉入编译范围？