【发布时间】：2011-08-18 18:19:19
【问题描述】：
请有人同时使用 Buildr 和 Gradle，并且可以比较这些构建工具。乍一看，它们非常相似。但是选择什么。而且很高兴听到有关 Scala 支持和各种 IDE 集成（IDEA、NetBeans、Eclipse）的信息。
谢谢。
【问题讨论】：
标签： scala ide comparison gradle buildr
【发布时间】：2011-08-18 18:19:19
【问题描述】：
我都尝试过使用，我肯定会推荐 Gradle。虽然它们都具有几乎相同的表现力，但我发现 Gradle 更加稳定（从 1.0 版开始）、安装工作量更少并且文档记录更好。尽管 Buildr 无疑是一项巨大的努力，但目前 Gradle 的制作更加专业。
我面对 Gradle 的唯一问题是缺乏对重用 ivy.xml（和 ivysettings.xml）的原生支持，尽管 Gradle 实际上使用 Ivy 作为其依赖引擎。此功能已承诺在不久的将来某个时间。另一方面，Buildr 有一个现成的插件（虽然它不是很可配置）。
如果您需要从 Maven 迁移，我将对这两种工具及其对您所需功能的支持进行一些调查。对于新项目，我推荐 Gradle。
两者都没有对 Eclipse 的良好支持，但 Gradle 有一个正在开发中的 Eclipse 插件，其工作方式与 Ant 插件非常相似。此外，Gradle 生成的 Eclipse 设置文件是高度可定制的，因此这是将其与 Eclipse 集成的另一种方式。
【讨论】：
-
我认为IDE集成对于大多数人来说绝对是一个杀手锏。就个人而言，我希望使用相同的编译器在 IDE 中构建我的文件，就像在其他任何地方（如构建服务器）运行时一样。
我同时查看了 gradle 和 buildr 并最终选择了 buildr，因为 gradle 的一个巨大缺点：构建系统的启动时间。 buildr 要快得多，并且给了我更快的增量构建。性能是我发现 gradle 几乎无法忍受的东西。只需考虑构建系统启动了多少次，然后将持续开销相加即可。
顺便说一句，我发现带有两个构建系统（buildr 和 gradle）的构建服务器不是很有用并且容易出错（也就是说：我花在故障排除上的时间比它实际加速的时间要多）。
【讨论】：
-
虽然我有点同意 gradle 的启动时间较慢，但 gradle 有很多内置逻辑不执行它已经完成的任务。我发现 UP-TO-DATE 的“功能”非常强大，即使使用自定义任务也很简单。另外，我相信由于 gradle 仍处于里程碑式的阶段，他们仍在解决功能上的问题。他们可能会以“让它发挥作用，让它正确，然后让它快速”的理念来接近这个项目。这意味着 gradle 不仅变得功能强大而且速度也很快。
-
Gradle 守护进程消除了启动开销并使 Gradle 更加灵活。
看看这是否有帮助（可能已经过时）：http://www.tikalk.com/alm/blog/buildr-vs-gradle
如果与 BuildR 相比，我推荐 Gradle： 1. 对于 JVM 生态系统，Groovy 比 Ruby 更“原生”。即使你使用 JRuby，你仍然需要安装很多 gem 2. BuildR的发展是爬行的。他们已经很久没有添加新功能了
话虽如此，我还是会质疑使用其中的任何一种：使用脚本编写任何任务的能力都会带来风险，即构建将有很多逻辑，人们需要先学习这些逻辑才能对其进行维护。由于这不是产品的主要逻辑，因此您可能会冒着人们不想维护构建或更糟的风险，以不正确的复制和粘贴方式进行操作（例如，性能方面）。使用 Maven，pom 中没有逻辑。此外，使用 Gradle/BuildR 意味着要构建产品，需要安装 Gradle/BuildR。 Maven 在这里更加标准。
【讨论】：
-
感谢您的回答。是的，我经常使用 maven，但认为它过于冗长且不灵活。但我也担心你所说的脚本构建工具，但想在我的玩具项目中尝试 Buildr 或 Gradle。
-
你甚至不需要手动安装 Gradle；相反，您可以使用 Gradle Wrapper，它会自动引导 Gradle（也在您的 CI 机器上）。
-
我不同意你建议在 gradle 上使用 maven。我过去都使用过，我对切换到 gradle 感到非常高兴。现在我有了灵活的构建和更短的构建脚本。这是一个双赢的局面。使用 gradle 时，我们的复制粘贴重复次数也少了很多。
-
如果您的构建不平凡，您需要在使用 maven 时编写自己的 maven 插件（如果它不重要，那么可维护性不是问题）。祝你好运，尝试通过脚本出售以实现可维护性。