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

我目前正在从Flyway中删除Spring依赖项。 在将来，虽然可能需要其他类型的依赖项来支持用户子集（例如JBoss VFS支持）。

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

解决方案的质量如下：

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

Answer 1

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

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

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

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

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

Answer 2

有以下选择：

• 将项目保持在一个单独的模块中; 并使用可选的依赖项。
• 将项目分成多个模块; 其中每个模块对任何库都有（非可选）依赖;

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

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

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

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