编写一个依赖于 Groovy 的库是个好主意吗？答案

【问题标题】：Is writing a library with a dependency on Groovy a good idea?编写一个依赖于 Groovy 的库是个好主意吗？
【发布时间】：2014-08-15 17:20:32
【问题描述】：

我现在正在编写一个 Java 库，我将它作为 Maven 工件发布并用于不同的 Java/Groovy 项目。我想知道编写一个依赖于特定版本的 Groovy 的库是否是一个好主意（例如，依赖于 groovy-all-2.x.y）。仅仅在库中使用 Java 的不适感并不会太糟糕。

你怎么看？我应该更好地为 Groovy 依赖项使用更大的版本范围吗？我应该写一个普通的 Java 库吗？

【问题讨论】：

我从来没有在库声明依赖范围方面有过很好的经验。你在你的库中使用了任何 Groovy 特性（闭包、元类等），还是只是用 Groovy 编写的？
它只是用 Groovy 编写的。所以迁移到 Java 应该不会太难。添加一些 getter、setter，添加一些分号。

标签： java maven groovy gradle

【解决方案1】：

我想这取决于您希望如何使用它。

如果它不是一个实用程序，并且您认为其他项目不会使用它，那么请随心所欲。
如果它是一个设计用于测试的实用程序，我不认为对测试类路径的常规依赖太糟糕了。我敢肯定，由于 groovy 依赖关系，某些项目仍会避免使用您的实用程序。
如果它是您希望人们在任何地方使用的通用实用程序，那么我会说 groovy 依赖项绝对是个坏主意。我当然不会使用它，而且我相信许多其他人会出于同样的原因避免使用它。

如果您希望最大程度地采用您的实用程序，请尽可能减少依赖项。 Groovy 是一个巨大的、臃肿的依赖项，许多项目都会避免。

【讨论】：

不错的答案，例如 HTTPBuilder 将其常规依赖范围从 compile 更改为 runtime 以避免冲突。
很可能是第 3 种情况，尽管它只会在公司内部被少数其他项目使用。但是 Groovy 版本可能仍然会发生冲突……
您通常会将此设置为provided 依赖项，并让消费者选择Groovy 版本。请注意，不保证主要的 Groovy 版本向后兼容，但次要版本可以。除了groovy-all，您可以使用特定的依赖项，例如groovy-core、groovy-sql 等。
@jack_kerouac 我猜有一个案例 4，那就是“它是一个仅用于 groovy 项目的实用程序”。在这种情况下，我认为将 groovy-all 添加为依赖项没有问题。由于“最近定义获胜”策略，使用您的实用程序的项目可以通过在自己的 pom 中指定 groovy-all 来覆盖版本。

【解决方案2】：

我会说这取决于这个库的预期用途。如果您只打算自己使用它并且完全可以使用 groovy 依赖项，那么就这样吧。如果该库是供其他人使用的，那么对他们来说最简单的事情可能就是用 Java 编写它，因为这样在尝试使用该库时出错的可能性就更少了。这真的归结为将其切换到 Java 所需的工作是否值得您将其全部使用 Java。

【讨论】：