我最近开始使用 Gradle 作为构建系统。
Gradle 与 Ant 和 Maven 之类的第一个比较是，
Ant 是 势在必行构建系统，而 Maven 是 声明性 构建系统。
而 Gradle 是一个声明式构建系统，没有 Maven 强制执行的刚性。
在谈论构建系统时，我想更好地理解这些声明性和命令性术语。
最佳答案
总之，一个 Ant 脚本告诉 Ant 工具该做什么 - “编译这些文件，然后将它们复制到该文件夹。然后获取该文件夹的内容并创建一个存档。”
而一个 maven pom声明 我们希望得到的结果 - “这里是项目所依赖的库的名称，我们想生成一个网络文件”。 Maven 知道如何获取库以及在哪里可以找到它自己的源类。
虽然 ant 为您提供了更大的灵 active ，但它也迫使您不断地重新发明轮子。
另一方面，Maven 需要较少的配置，但可能会感觉过于受限，特别是如果您习惯了不同的工作流程。
编辑: ant-maven 比较的一个重要方面是 maven 有一个 公约 ，描述文件应该放在哪里，在哪里找到依赖项，在哪里放置生成的 Artifact ，而 ant 没有。
因此，您可以将使用 maven 想象为乘坐公共(public)汽车 - 您选择进入的站点和离开的站点。使用 ant 就像开车一样——你必须自己动手。您不必告诉巴士司机该做什么，但停靠站可能离您想去的地方太远。
EDIT2: “重新发明轮子”的比喻似乎没有我希望的那么清晰。这就是我的意思:
如果没有合理的默认值/约定，您必须为每个项目明确定义项目结构和构建生命周期，这通常使其成为品味和意见的问题。由于团队和公司之间的偏好不同，因此构建流程也是如此。这需要新项目成员和后来的维护者付出更多的认知努力。根据开发人员的经验和专业知识，最终的解决方案可能难以扩展和使用。
正如我在下面的评论中所说，虽然存在 ant 构建的最佳实践，但它们仍然必须为每个项目实现，或者从一个项目复制粘贴到另一个项目，而不是成为构建的开箱即用默认值工具本身。
对于我的口味，Maven 在权衡的另一边有点过分了。更改默认值并不像它可以而且应该那样容易。
关于maven - 命令式与声明式构建系统，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14955597/