Build 选择脚本/构建工具

我们目前正在使用actionscript和Java进行一个项目。到目前为止，我们使用Ant作为主要的构建工具，但它意味着大量的重复和缺乏灵活性（我们正在构建大量的小型子项目，每次复制所有的构建文件都是一件痛苦的事情），这促使我们改变工具

EDIT3：我已经在Gant中重写了我们所有的构建，尽管它并不完美，但它大幅缩减了我们的构建文件，并使添加新项目变得更加简单，因此我向那些不想改变构建理念和项目结构，只想寻找比ant更方便的工具的人推荐Gant。也许有一天我会去看看格拉德尔和/或常春藤

EDIT2：在试用Buildr之后，我们排除了它，因为它做的事情比我们实际需要的要多。我现在正在尝试Gant，它看起来正是我们需要的，但文档非常小。是否值得一路搬到格拉德尔，还是这个项目还不够成熟

编辑：我将尝试澄清我们与Ant之间的问题。我们有几个具有类似布局的子项目，我们必须为它们编译和运行测试。完成后，其中一些需要打包在一起以生成可执行文件（即客户端、服务器和一些独立演示）。在ant中描述我们的标准布局的工作相当长，在不重写整个宏的情况下引入小的变化是非常困难的。（比如，其中一个项目需要从另一个存储库获取其可视化资产）

• 这将允许我们重用已经存在于Flash和Java中的ant任务
• 出于同样的原因，尽管它看起来稍微复杂一些
• 这似乎是强烈推荐的。缺点是对动作脚本集成的实验性支持以及我们对Ruby的缺乏了解
• 这看起来很酷，但在这里，对ruby一无所知
• 看起来势头不大，但Python是一种非常酷的脚本语言

Maven曾被考虑过，但由于其固有的复杂性和明显的错误倾向性而被淘汰。我们目前倾向于甘特图。你们中有人有使用这些工具的经验吗？他们如何比较

---

我们的需求非常基本：编译和打包项目，将它们部署到多个目标和一些脚本功能（例如运行特定于项目的性能测试）。值得注意的是，我们使用Hudson来处理持续集成。

我知道，我们公司以Java为生的人对Ivy发誓，但对它没有任何经验，我没有足够的事实来支持这一建议。他们确实提到，与以前使用的Ant相比，缺少复制是一个优势。买主注意。

我不确定切换到甘特是否能解决您的问题。甘特只是用groovy而不是xml编写构建文件。我认为你的问题更多地在于你使用ant的方式。很难说没有更多的细节，但像“大量重复”和“复制构建文件”这样的短语让我觉得您可以更有效地使用ant

如果您还没有，请查看您的ant任务，看看是否可以重构它们以消除重复。此外，如果您还没有看到ant，请将-find选项签出给ant。您不需要到处复制构建文件

---

顺便说一句，Ivy用于依赖关系管理，而不是构建。

为了澄清，我们所有的构建文件都位于同一个目录中，我们实际上并没有在项目中复制它们。然而，在ant中执行可参数化的任务仍然非常复杂（很大程度上是因为xml不是一种非常令人愉快的编程语言），大致上，我们希望能够独立地构建子项目，然后将它们打包在一起，而不必在构建文件中复制相同的任务十次。