java - 我什么时候需要具有运行时范围的 Maven 依赖项

Question

我试图了解 Maven 中对 runtime 作用域依赖的特定需求。在哪种情况下我会需要这个，compile 或 provided 作用域都不行？

例如，当我必须在代码中直接调用库 API(对其进行编译)并将依赖项打包到 Artifact 或依赖项目 Artifact 中时，我会使用 compile 范围作为依赖项。

当我必须针对 API 进行编译时，我会使用 provided 范围，但不打包它(除非它在运行时可用)。

但是我什么时候需要运行时范围？这是否适用于我不直接调用库 API(而是使用反射)但想将其打包到 Artifact 中的情况？为什么不直接使用 compile 作用域呢？唯一的好处是更快的编译时间，还是 runtime 范围内有其他特殊的东西无法通过 compile 范围实现或避免？

Answer 1

您可以在 runtime 范围内做的所有事情也可以在默认范围内完成:compile。
那么为什么要使用runtime呢？

因为在某些情况下，这非常有意义并且可以使您的构建更加健壮。

一个典型的用例是确保客户端代码不使用特定的实现。

假设您构建一个依赖于打包为 Maven 依赖项 (my-service-api) 的 API 的应用程序，并且此 API 的实现被打包为另一个 Maven 依赖项 (my-service -impl).
假设现在您需要在构建的应用程序中在运行时提供实现，但您不希望您的应用程序的客户端代码直接引用该实现。

通过为 my-service-impl 使用 runtime 范围:

<dependencies>
​  <dependency>
​      <groupId>my-group</groupId>
​      <artifactId>my-service-api</artifactId>
​  </dependency>
​  
​  <dependency>
​      <groupId>my-group</groupId>
​      <artifactId>my-service-impl</artifactId>
​      <scope>runtime</scope>
​  </dependency>
<dependencies>

由于编译器永远不会在类路径中具有依赖性，因此您不能在应用程序的客户端代码中与实现创建任何耦合。
客户端代码只会看到依赖项的 API:

通过为 my-service-impl 使用 compile 范围:

<dependencies>
​  <dependency>
​      <groupId>my-group</groupId>
​      <artifactId>my-service-api</artifactId>
​  </dependency>
​  
​  <dependency>
​      <groupId>my-group</groupId>
​      <artifactId>my-service-impl</artifactId>    ​  
​  </dependency>
<dependencies>

情况有所不同:您可能会错误地引用实现类，从而与实现产生不希望的耦合。

支持运行时范围的已知用法是您必须处理特定 DBMS(Oracle、PostgreSQL 或其他)的 JDBC 依赖性。
要编写可移植代码，您不想让客户端代码引用此 JDBC 依赖项的类，但您希望将它包含在您的应用程序中，因为在运行时需要类来使 JDBC api 与此 DBMS 一起工作.