java 处理可选依赖项的最佳策略

Best strategy for dealing with optional dependencies

提问by Axel Fontaine

I'm currently in the process of removing the Spring dependency from Flyway. In the future though other types of dependencies might be needed to support a subset of users (such as JBoss VFS support).

我目前正在从Flyway中删除 Spring 依赖项。尽管将来可能需要其他类型的依赖项来支持一部分用户（例如 JBoss VFS 支持）。

Which is the best way to support optional dependencies(optional=true in Maven POM)?

哪个是支持可选依赖项的最佳方式（Maven POM 中的 optional=true）？

Qualities of the solution would be:

解决方案的质量将是：

• Ease of use for end-users (minimum work required to use functionality if dependency is present)
• Ease of use for developers (code dealing with optional dependency should be as readable and as straightforward as possible)
• No unnecessary required dependencies (if some end-user don't need this functionality, no need to pull in the dependency)

• 易于最终用户使用（如果存在依赖性，则使用功能所需的工作最少）
• 易于开发人员使用（处理可选依赖项的代码应尽可能可读和直接）
• 没有不必要的必需依赖（如果某些最终用户不需要此功能，则无需引入依赖）

回答by Mark O'Connor

I think Maven's optional dependency functionality is quite limited.

我认为 Maven 的可选依赖功能非常有限。

http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

Optional dependencies will not get pulled down (as transitive dependencies) by default. However, if your users need to use these optional features the missing dependencies must be explicitly declared, in their POM.

默认情况下，可选依赖项不会被下拉（作为传递依赖项）。但是，如果您的用户需要使用这些可选功能，则必须在他们的 POM 中显式声明缺少的依赖项。

Personally, it's not clear to me how this is helpful to users.... I suppose the optional dependencies in your POM do document which versions your code depends on. Not all users however will read the POM, all they'll see is the "NoClassDef Found" error :-(

就我个人而言，我不清楚这对用户有什么帮助......我想你的 POM 中的可选依赖项会记录你的代码所依赖的版本。然而，并非所有用户都会阅读 POM，他们只会看到“NoClassDef Found”错误:-(

My final observation is that this is one of those rare scenarios where a dependency manager like ivyoffers more flexibility. Ivy has a concept called "configurations". Module authors can assemble different combinations of dependencies, for example "with-spring" or "without-spring".

我的最后观察是，这是像ivy这样的依赖管理器提供更多灵活性的罕见场景之一。Ivy 有一个叫做“配置”的概念。模块作者可以组装不同的依赖组合，例如“with-spring”或“without-spring”。

回答by Martin Ellis

There's a choice of:

有以下选择：

• keep the project in a single module; and use optional dependencies.
• split the project into multiple modules; where each module has a (non-optional) dependency on any libraries;

• 将项目保存在单个模块中；并使用可选的依赖项。
• 将项目拆分为多个模块；其中每个模块对任何库都有（非可选）依赖；

I think the first makes more sense in most cases: users need to figure out their way around fewer artifacts. Typically, they'll have to add fewer new dependencies to their pom. Unless the code to support third-party projects is large, this will help improve maven download times too (fewer round-trips). With the latter approach, you can find yourself in awkward situations where the user has defined their own set of versions, but only for some of the third-party dependencies.

我认为第一个在大多数情况下更有意义：用户需要找到解决更少工件的方法。通常，他们将不得不向他们的 pom.xml 添加更少的新依赖项。除非支持第三方项目的代码很大，否则这也将有助于改善 maven 下载时间（更少的往返次数）。使用后一种方法，您会发现自己处于尴尬的境地，即用户定义了自己的一组版本，但仅限于某些第三方依赖项。

I prefer to see the optional dependencies in the pom (I sometimes look to see which version it's built against). It's true that some people might not look. I think copy-and-pasteable pom snippets on the website is the best solution for that. For example, if you have a page about Spring integration, you could put the relevant pom snippet on that page.

我更喜欢在 pom 中查看可选的依赖项（我有时会查看它是针对哪个版本构建的）。确实，有些人可能不看。我认为网站上可复制和粘贴的 pom 片段是最好的解决方案。例如，如果您有一个关于 Spring 集成的页面，您可以将相关的 pom 片段放在该页面上。

I'd suggest that non-free dependencies (or anything not easily resolvable) be kept in a separate maven module, so that contributors are always able to build the primary artifact. (I had that problem with Quartz, which IIRC has an optional dependency on an Oracle JDBC jar).

我建议将非自由依赖项（或任何不容易解析的）保存在单独的 maven 模块中，以便贡献者始终能够构建主要工件。（我对 Quartz 有这个问题，它 IIRC 对 Oracle JDBC jar 有一个可选的依赖）。

Edit: If you're worried about users seeing NoClassDefFoundErrors, it wouldn't do any harm to check that the class can be resolved before trying to use it. For example, you could can an exception, and throw a more meaningful error message pointing the user to documentation. SLF4J is a good example of this.

编辑：如果您担心用户看到 NoClassDefFoundErrors，那么在尝试使用该类之前检查该类是否可以解析不会有任何危害。例如，您可以抛出异常，并抛出一条更有意义的错误消息，将用户指向文档。SLF4J 就是一个很好的例子。