Spring Boot 应用程序中的多个 Spring Data JPA 模块（非 Spring Boot）依赖项？答案

【问题标题】：Multiple spring data jpa modules(non spring boot) dependencies in a Spring boot app?Spring Boot 应用程序中的多个 Spring Data JPA 模块（非 Spring Boot）依赖项？
【发布时间】：2021-01-01 14:22:15
【问题描述】：

我们正在构建独立的可重用 Spring Data jpa 模块没有 spring boot。我们称它们为数据库模块。这些模块将被导入另一个 Spring Boot 应用程序。在 db 模块中，我们包括

<dependency>
   <groupId>org.springframework.data</groupId>
   <artifactId>spring-data-jpa</artifactId>
   <scope>provided</scope>
</dependency>

但是，我们在主弹簧靴中包含了

<dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

db 模块中的所有 spring 依赖项都是在主 spring boot 应用程序提供的运行时提供的范围内提供的。这是正确的做法吗？

此外，每个 db 模块是否应该有自己的用于 db 连接的属性文件，或者它们是否应该回复主 spring boot 应用程序。所有 db 模块都连接到同一个数据库。这些模块代表应用程序中的不同域。

【问题讨论】：

提供的范围是不可传递的，依赖不会被拉入依赖于数据库模块的项目中。那是你要的吗？您希望启动器将其拉入吗？
这就是我们想要实现的目标。所有这些 db 模块都继承自一个父 pom，该 pom 包含所有这些具有提供范围的依赖项。消费环境（spring boot app）向这些数据库模块提供这些依赖关系不是更好吗？或者所有这些数据库模块都应该带来它们自己的依赖关系吗？这可能会导致问题，因为主 Spring Boot 应用程序也将具有 Spring 核心依赖项，并且如果它们位于不同版本上，可能会导致类路径污染。
简答：所有这些 db 模块都应该自带依赖项。
“如果它们在不同的版本上，可能会导致类路径污染” 这取决于打包应用程序以进行部署以解决此类差异的构建脚本。 Maven 通常会自动为您执行此操作。如果你不声明你依赖的其他库，你怎么知道是否存在需要解决的冲突。在代码运行失败之前您不会知道，并且在已经部署用于生产之前您可能不会检测到这一点，因此您只是使生产服务器崩溃，因为在构建过程中应该检测到一些东西。
@Andreas fair pont

标签： java spring spring-boot maven spring-data-jpa

【解决方案1】：

不，使用<scope>provided</scope> 是不正确的。

正如 Maven documentation 所说：

提供
这很像compile，但表示您希望JDK 或容器在运行时提供依赖项。例如，在为 Java 企业版构建 Web 应用程序时，您可以将 Servlet API 和相关 Java EE API 的依赖设置为范围 provided，因为 Web 容器提供了这些类。具有此范围的依赖项被添加到用于编译和测试的类路径中，而不是运行时类路径中。它不是传递的。

换句话说，它是由运行时在部署程序集之外“提供”的。

如果在打包代码以进行部署时必须包含依赖项，那么您肯定不会期望它是 provided。

请记住，您的库需要告诉依赖于您的库的构建系统，它需要什么来包含其他库以及您的库。这就是传递依赖的全部目的，所以如果不让 spring-data-jpa 成为传递依赖，你就错了。

【讨论】：

好的，我理解所提供范围的要点。数据源配置怎么样。每个模块应该有自己的配置还是应该由主应用程序提供？
@bluelurker 该模块是可重用的。它不知道如何连接到数据库。这是由应用程序决定的，而不是模块，对吧？
是的，数据库模块是可重用的。它们将来会被其他 Spring Boot 应用程序使用。是的，它们不能作为独立的应用程序存在
我认为这是不对的。 provided 的使用方式比此处纯粹描述的方式更多。我已经将它用于与 OP 类似但不相同的情况。 Lombok 建议您使用提供的范围，纯粹是为了避免传递依赖，即使它用于编译您的代码。虽然容器可能是此范围的意图，但我认为超出其意图的用例不一定是错误的。
@Michael 如果您的模块包含需要额外依赖项的可选功能，但它们被认为是可选的，因为模块的使用可能不需要该特定功能，因此不需要不需要额外的依赖项，那么是的，provided 是一个有效的选择。 --- 您的模块并非如此，因为您使用provided 抑制的传递依赖是强制，所以抑制依赖是完全错误的。当然可以，因为应用程序也会包含它们，但这并不正确。