Maven1.0已经历了几年的时间，并且作为Ant的替代品已被广大的开发人员所接收，但它并没有在很大程度使开发人员从Ant的build.xml文件中解脱出来。
Maven1.0速度慢并且笨拙，使用起来的困难度并不亚于使用Ant的项目。
事实上，它的核心是基于Ant实现的。在经过了几乎彻底的重写后，Maven2.0诞生了。
一个Java项目中最困难的地方就是如何着手启动它。
在启动项目之前，我们必须配置好所有的逻辑关系。比如，Java源代码应该放在何处？单元测试应该在何处进行？依赖的jar包应该如何放置？如何构建项目，如何形成文档，如何测试和部署项目？在这种情况下，开发人员不同的处理选择将会影响项目的余下部分。
您的选择可能会使你陷入困境，也可能会在将来证明您是一位Java架构大师。
我们假定后者是我们奋斗的目标，接下来就进入我们的正题。
构建一个Java项目可以使用很多工具，其中包括Ant。Ant作为一款具有革命性的工具，一直是众多开发者使用工具中的首选，它能使开发人员摆脱使用大量 make命令的苦海。
对于那些不太熟悉make命令的人来说，他们有充足的理由来表明使用命令并不是构建Java项目的最好工具，因为它不具备平台独立性并且不易使用。
Ant的出现解决了以上的问题，它使用了一个平台独立的工具，该工具能够解析XML配置文件，即build.xml。虽然Ant由于其诸多的优点而备受欢迎，但它同样有一些缺点。
build.xml文件由于采用了极其简短的描述方式，使得开发人员需要预先学习它的语法。虽然学习曲线不是很陡峭，但Java开发人员更应该把时间放在开发上面。
Maven是新一代的生力军，它的境遇正好和几年前的Ant十分类似。 Maven1.0已经历了几年的时间，并且作为Ant的替代品已被广大的开发人员所接收，但它并没有在很大程度使开发人员从Ant的build.xml文件中解脱出来。
Maven1.0速度慢并且笨拙，使用起来的困难度并不亚于使用Ant的项目。
事实上，它的核心是基于Ant实现的。在经过了几乎彻底的重写后，Maven2.0诞生了。