Ant -＞ Maven -＞ Gradle发展过程

1:Ant 的结构构成：

Ant 没有对如何定义构建的结构强加任何限制。这样让适应一个现有的项目结构变得简单。例如，在样例脚本中，源代码目录和输出目录是随意选择的。通过修改相关的属性可以非常轻松地改变它们。对于target的定义也是一样的；对于每个target，哪个逻辑需要被执行，以及它们的执行顺序，你拥有完全灵活的选择性。

缺点：

1. 使用XML作为构建逻辑的定义语言相比于其他更简洁的定义语言，会导致构建脚本过于臃肿和啰嗦
2. 复杂的构建逻辑会导致又长又难以维护的构建脚本。当尝试用标记语言去定义类似if-then/if-then-else的逻辑语句时，它完全就成了一种负担
3. Ant没有提供任何指导来告诉你如何建设项目。在一个企业级配置中，这常常会导致一个build文件每一次看上去都不一样。常用功能时常被到处拷贝。项目中每一个新的开发人员都需要去理解构建中每一个独立的部分
4. 你想要知道在构建中有多少个类被编译或者多少个task被执行。Ant没有暴露任何的API能够让你在运行时获取内存模型的信息
5. 在没有Ivy的情况下，使用Ant很难管理依赖。在通常情况下，你需要将JAR文件提交到版本控制系统中，并且手动管理组织结构

2：Maven【约定优于配置思想，提供一些配置的默认值】

缺点：

1. Maven 推荐一个默认的结构和生命周期，常常会太过限制，也许不适合项目需求
2. 为Maven 写定制的扩展过于累赘。你需要去学习Mojos【Maven 的内部扩展API】，如何提供一个插件描述符（又是XML），以及相关的特殊注解，以便扩展实现所需要的的数据
3. Maven 的早期版本（低于2.0.9）会自动尝试更新它们自己的核心插件。例如，将单元测试的支持插件升级到最新版本。这可能会导致脆弱和不稳定的构建

3：对下一代构建工具的需求

我们了解了Ant和Maven工具的特性。要么选择完全灵活且可扩展，但很难实现项目标准化，有一堆公式化代码，并且没有依赖管理支持的Ant【灵活，非标准化】；要么选择Maven，它能提供约定优于配置的方式和无缝的依赖管理器集成，但过于限制思维和拥有臃肿的插件系统【标准化，不灵活】

从而产生了新的构建工具 Gradle！