如何处理基于 Spring Boot 的库和不匹配的 Spring Boot 版本

Question

我们正在运行多个服务，并且希望转移到库中获取一些通用代码，因为复制和粘贴不再有效。

我确实有一些自定义 Spring Boot 启动器的经验，但想知道如何处理我过去遇到的一个常见问题：库和包含它们的服务之间的 Spring Boot 版本存在差异。

这是一个简短的例子：

my-library is based on SB 3.0.1
my-service is based on SB 3.0.3

通常可以使用

my-service

隐式强制

SB 3.0.3

，但我想避免这种情况，因为我们在执行此操作时遇到了一些令人讨厌的问题（例如

my-library

的测试对于

SB 3.0.1

是绿色的，但会失败

SB 3.0.3

，这将不会被检测到并导致部署被巧妙地破坏，因为例如，不再导出经过专门测试以存在于

my-library

中的特定指标 - 这最近会发生在我们的

SB 3.0.9

中） .

如何配置我的 gradle 项目以在这种情况下不允许使用两个不同的 Spring Boot 版本？ 我想知道是否有一个分类器，例如

my-library:1.0.1:sb3.0.1

适用于此，但我不知道是否例如翻新将支持所需的依赖声明：

my-library:${my-lib-version}:sb${sb.version}

我正在寻找一种优雅的方式，无需为每个 Spring Boot 版本更新手动调整我的

build.gradle.kts

，因为我们维护了太多单独的服务，因此这是可行的。如果可能的话，我想避免任何类型的自定义项目父设置（就像 Spring Boot 的 Maven 集成的情况一样）。

Answer 1

https://docs.gradle.org/current/userguide/dependency_resolution.html

默认：

Gradle 将考虑所有请求的版本，无论它们出现在依赖关系图中的任何位置。在这些版本中，它将选择最高的一个。

如果您的库定义了更高版本，并且使用项目没有定义任何附加约束，那么您的库版本将获胜。

但是，如果您的消费项目管理自己的依赖项（这对于使用 依赖管理插件 或 平台 或 版本目录 时的 Spring Boot 项目来说是典型的情况），那么消费者定义的版本可能会在依赖项解析过程中获胜。

最终，您必须修改每个项目的构建以遵守您的库版本。这可以通过发布平台 (BOM) 或版本目录来完成，然后您的消费者将使用它来代替 Spring Boot BOM。

因此，例如：

dependencies {
    implementation(platform(SpringBootPlugin.BOM_COORDINATES))
}

你会这样做：

dependencies {
    implementation(enforcedPlatform("com.example:my-library-platform:1.0.0"))
}

但是正如您提到的，您有几个项目。 OpenRewrite 等工具可以通过自动化该过程来提供帮助。或者在 CI/CD 解决方案中，您可以创建/定义全局初始化脚本来自定义构建。