我什么时候需要与运行时范围的maven依赖 [英] When would I need maven dependency with runtime scope

问题描述

我正在尝试了解maven中运行时作用域依赖项的特定需求。在哪种情况下我需要这个，其中编译或提供的范围不会吗？

I'm trying to understand the specific need for runtime scoped dependency in maven. In which situation I would need this, where neither compile or provided scope won't do?

例如，当我必须直接在代码中调用库API时，我会使用 compile 作为依赖项的范围（针对它编译）并将依赖项打包到工件或依赖项目工件中。

For example, I would use compile scope for dependency, when I have to call the library API directly in the code (compile against it) and package the dependency in the artifact or dependent project artifacts.

我必须使用提供范围针对API进行编译，但不打包它（除了它在运行时可用）。

I would use provided scope when I have to compile against the API, but don't package it (rather except it to be available at runtime).

但我什么时候需要 runtime 范围？这是针对什么情况，当我不直接调用库API（而是使用反射），但是想要将它打包到工件中？为什么不只是使用编译范围？唯一的好处是编译时间更快，或者在运行时范围内是否存在其他特殊功能 compile 范围？

But when would I need runtime scope? Is this for situations, when I don't directly call the library API (rather use reflection), but want to package it inside the artifact? Why not just to use compile scope? Is the only benefit faster compile time, or is there something other special in runtime scope that couldn't be achieved or avoided with compile scope?

推荐答案

使用运行时范围也可以使用默认范围： compile 。

为什么要使用 runtime ？


All what you can do with the runtime scope can be also done with the default scope : compile.
So why use runtime?

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

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

A typical use case is ensuring that the client code doesn't use a specific implementation.

假设你构建依赖于打包为Maven依赖项（ my-service-api ）的API的应用程序，此API的实现打包为另一个Maven依赖项（ my-service-impl ）。

假设现在你需要在构建的应用程序的运行时提供实现，但你不想要：应用程序的客户端代码直接引用实现。

Suppose you build an application relying on an API packaged as a Maven dependency (my-service-api) and the implementation of this API is packaged as another Maven dependency (my-service-impl).
Suppose now you need to provide the implementation at the runtime in the built application but you don't want that the client code of your application refers directly the implementation.

通过使用运行时范围 my-service-impl ：

<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：

As the compiler will never have the dependency in the classpath, you cannot create any coupling with the implementation in the client code of your application.
Client code will only see the API of the dependency :

通过使用编译 范围：

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

情况有所不同：你可能会错误地引用实现类，因此会与实现产生不良的耦合。

Things are different : you could by mistake reference implementation classes and so create an undesirable coupling with the implementation.

支持 runtime 范围的已知用法是必须处理特定DBMS的JDBC依赖关系（ Oracle，PostgreSQL等等。

要编写可移植代码，您不希望允许客户端代码引用此JDBC依赖项的类，但您希望所有相同的内容都包含在您的应用程序中，如同运行时需要使JDBC api与此DBMS一起使用。

A known usage to favor runtime scope is as you have to cope with a JDBC dependency of a specific DBMS (Oracle, PostgreSQL or whatever).
To write portable code, you don't want to allow the client code to refer to classes of this JDBC dependency but you want all the same include it in your application as at runtime the classes are needed to make the JDBC api works with this DBMS.

这篇关于我什么时候需要与运行时范围的maven依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！