java - 可选的编译时依赖项如何工作？

Question

在很长一段时间里，我认为在 Java 中你要么有两种依赖类型之一:

所需的编译时依赖项(编译时始终需要依赖项)

可能是可选的运行时依赖项(可以是
在运行时解决)

最近，我发现编译依赖也可以是可选的。例如， commons-beanutils被列为 optional compile dependency的 JXPath .

这怎么行？是否真的可以在编译时使用依赖项但仍然是完全可选的？

编辑:我可能不清楚。我正在寻找在编译时使用依赖项并且同时完全可选的情况，或者解释为什么这种依赖项是不可能的。

Answer 1

来自 Maven documentation 的广泛引用非常清楚地描述了这一点:

Optional dependencies are used when it's not possible (for whatever reason) to split a project into sub-modules. The idea is that some of the dependencies are only used for certain features in the project and will not be needed if that feature isn't used. Ideally, such a feature would be split into a sub-module that depends on the core functionality project. This new subproject would have only non-optional dependencies, since you'd need them all if you decided to use the subproject's functionality.

However, since the project cannot be split up (again, for whatever reason), these dependencies are declared optional. If a user wants to use functionality related to an optional dependency, they have to redeclare that optional dependency in their own project. This is not the clearest way to handle this situation, but both optional dependencies and dependency exclusions are stop-gap solutions.

Why use optional dependencies?

Optional dependencies save space and memory. They prevent problematic jars that violate a license agreement or cause classpath issues from being bundled into a WAR, EAR, fat jar, or the like.

How do optional dependencies work?

Project-A -> Project-B

The diagram above says that Project-A depends on Project-B. When A declares B as an optional dependency in its POM, this relationship remains unchanged. It's just like a normal build where Project-B will be added in Project-A's classpath.

Project-X -> Project-A

When another project (Project-X) declares Project-A as a dependency in its POM, the optional nature of the dependency takes effect. Project-B is not included in the classpath of Project-X. You need to declare it directly in the POM of Project X for B to be included in X's classpath.

一个实际的例子:假设你是一个库/框架的开发者 SuperLib被构建为一个 superlib.jar .您的库提供多种功能。它的主要功能(大多数用户使用的)是基于第三方的依赖注入(inject) di图书馆。然而，你的一门课 - EmailApi - 提供使用第三方发送电子邮件的功能 email图书馆。由于 superlib是一个 Artifact ，它需要两个 di和 email要编译。

现在把自己放在使用 superlib 的用户的位置上。 .他们对依赖注入(inject)功能感兴趣。这是你的库的核心角色，所以 superlib之间的依赖关系和 di不会是可选的。

但是，大多数用户对发送电子邮件不感兴趣，并且可能会被无用的 email 所困扰。库及其依赖项添加到他们的应用程序(这将导致他们的应用程序的大小增加，并可能导致 email 的依赖项和用户应用程序的依赖项之间的依赖项版本冲突)。因此，您将标记对 email 的依赖。如 optional .只要用户不使用你的 EmailApi上课，一切都会好起来的。但是，如果他们确实使用 EmailApi ，他们将需要 email依赖关系，否则应用程序将在运行时失败，并出现 email 中的任何类的 ClassNotFoundException将在 EmailApi 中引用.您图书馆的用户需要添加 email在他们的 POM 中显式地依赖。

另见 When to use <optional>true</optional> and when to use <scope>provided</scope> .