Gradle：Springboot重写依赖项（jersey和apache http客户端）

Question

我有一个非常简单的用于测试目的的springboot应用程序。

这是我的身材。格拉德尔：

plugins {
  id 'org.springframework.boot' version '2.1.0.RELEASE'
  id 'io.spring.dependency-management' version '1.0.8.RELEASE'
  id 'java'
}

sourceCompatibility = '1.8'

repositories {
  mavenCentral()
}

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-web'
  implementation 'org.mandas:docker-client:2.0.2'
}

org。mandas:docker client:2.0.2对组织具有可传递的依赖关系。玻璃鱼。运动衫核心：jersey客户端：2.28。然而，gradle随后拉取版本2.27，而不是2.28。

如果我运行/gradlew dependencyInsight——依赖组织。玻璃鱼。运动衫core:jersey客户端我得到以下输出：

org.glassfish.jersey.core:jersey-client:2.27 (selected by rule)
...
org.glassfish.jersey.core:jersey-client:2.27
\--- org.glassfish.jersey.connectors:jersey-apache-connector:2.27
     \--- org.mandas:docker-client:2.0.2 (requested org.glassfish.jersey.connectors:jersey-apache-connector:2.28)
          \--- compileClasspath

org.glassfish.jersey.core:jersey-client:2.28 -> 2.27
\--- org.mandas:docker-client:2.0.2
     \--- compileClasspath

似乎springbootstarterweb在某种程度上依赖于org。玻璃鱼。运动衫核心：jersey客户端：2.27。但是，如果我使用打印所有依赖项/gradlew dependencies我在组织上看不到依赖关系。玻璃鱼。运动衫核心：jersey客户端：2.27来自spring boot starter web。

然而，在网上搜索了一下，我发现了另一种追踪依赖性的方法：

grep -r "2.27" ~/.gradle/caches/modules-2/files-2.1/*

这样，我就能够追踪到版本2.27是在哪里引入的。似乎在以下POM中声明：

• Spring引导依赖项2.1.0。发布. pom
• Spring引导-自动配置-2.1.0。发布. pom

我现在的问题是多方面的：

• 首先，为什么sping-boo-starter-web依赖于jersey？我总是有这样的印象，如果我们想显式地使用jersey而不是Spring实现，我们将包括sping-boo-starter-jersey。
• 为什么我看不到sping-boo-starter-web依赖于org.glassfish.jersey.core： jersey-Client： 2.27运行./gradlew依赖项。显然，当它降级版本时，一定有对它的依赖。
• 为什么2.28版本降级到2.27版本？我如何知道Spring引导应用哪个策略，以便为特定版本做出选择。
• 应用程序运行得非常好，但是现在我有一个版本冲突，我应该如何最好地处理这个问题？仅仅使用v2.28而不是v2.27是可行的选择吗？我想这也指的是我的第一个答案，关于为什么Spring Boot实际上使用泽西。

我知道这些是多个问题，但我认为最好是在一个问题中提问，而不是将它们分散在多个问题上，因为它们都与同一个上下文相关。

顺便说一句：这不仅仅发生在org上。玻璃鱼。运动衫核心：jersey客户端。同样的事情也适用于org。阿帕奇。httpcomponents:httpclient。

谢谢你的帮助！

Answer 1

首先，为什么sping-boo-starter-web依赖于泽西？我总是有这样的印象，如果我们想显式地使用jersey而不是Spring实现，我们将包括sping-boo-starter-jersey。

不是，而是取决于Tomcat。您正确地认为您需要jersey启动器来自动配置它。

为什么我看不到运行./gradlew依赖项时依赖于org.glassfish.jersey.core： jersey-Client： 2.27。显然，当它降级版本时，一定有一个依赖它的地方。

因为它没有。下面有更多信息。

为什么2.28版降级到2.27版？我如何知道spring boot应用了哪种策略来选择特定的版本。

这是根本问题。我将在下面解释。

应用程序运行得非常好，但是现在我遇到了版本冲突，我应该如何最好地处理这个问题？使用v2是否可行。28而不是v2。27.我想这也是我第一次回答为什么spring boot会使用jersey。

视情况而定。根据我的经验，您的依赖关系可以通过升级和降级一个可传递的依赖关系来打破，与它们已经构建和测试过的依赖关系相比，即使它只是一个次要版本（我在看您，SnakeYAML！）所以你真的需要试一试。通常升级比降级更安全，但有时仍会导致问题。

这是关于泽西岛降级的交易。

Spring依赖项管理插件用于控制依赖项的版本，包括直接依赖项和可传递依赖项。

当您同时应用依赖项管理插件和Spring Boot插件时，后者将应用其默认版本，该版本来自Spring BootBOM。通过运行gradle dependencyManagement，您可以检查管理了哪些依赖项以及在哪些版本中。

所有这些的想法是，您可以得到一组相互之间工作良好的依赖关系。如果您喜欢其中一个托管依赖项的不同版本，则必须使用dependencyManagement扩展对其进行配置（如本文所述）。

这就是为什么您的Jersey依赖项会降级。

我个人不使用Spring依赖项管理插件，因为我喜欢在plain Gradle中处理依赖项的方式。所以我通常会这样做：

plugins {
  id 'org.springframework.boot' version '2.1.0.RELEASE'
  id 'java'
}

dependencies {
  implementation platform("org.springframework.boot:spring-boot-dependencies:2.1.0.RELEASE")
}

在这种情况下，它将默认使用Spring Boot BOM中的依赖项，但如果有人需要更新版本，则不会降级。但是如果需要，它会升级它们，如果你不想的话，你也不必自己指定版本，在这种情况下，它会使用BOM中的版本。