有可能出自兼容性的考虑、或者是灵活性的考虑、又或者是考虑去除某些用户心理上的ＦＵＤ，或者几者兼有之，反正Maven是支持Ant脚本的执行的。(具体请看Guide to using Ant with Maven, http://maven.apache.org/guides/mini/guide-using-ant.html)
      Maven将Ant作为一种包含的关系存在，我们可以想象的到Maven应该是在某些方面有超越Ant的表现的，比如在功能上，Maven提供的网站生成与包依赖管理管理特色功能是Ant没有原生提供的。
      比如包依赖管理，包依赖管理真的是很强大且实用的功能，想想我们每个工程都有无数的第三方包需要管理，而这些包进行人工管理（想想人工分析包的版本，第三方包与包之间的依赖等等）真的是一件令人痛苦的事情，引入包依赖管理后，包统一自动管理是多么美妙的一件事情？当然这个功能想用在Ant中也不是不行的！(具体可以看看江南白衣的<<做环保主义者，用Maven2 管理Java类库>>( http://www.blogjava.net/calvin/archive/2006/03/19/36098.html)，由于是Ant去调用了Maven，Maven和Ant肯定是并存于工程中了，也许这样会让一些Ant的铁杆Fans会觉得这样在工程中并不干净了，只是需要Maven提供的一个额外功能就引进了整个Maven，如果是这样， Ant+Ivy的组合对包进行依赖管理可以是另一种选择。
      对于网站的生成，个人感觉这个Ant是可以做到的，提供对应的插件就行了！在google中搜索到这个网站AntDoc web site(http://antdoc.free.fr)好像是提供了类似功能，不过可惜的是我这里打开不了这个网站，并不能肯定是否可行。
      这样子比较下来，好像Ant与Maven又回到了原点，至少Maven能得到的，Ant一样能做到。
      总结一下，我们可不可以这样子理解，Maven以一种包含的关系提供对Ant脚本的支持，只是在内部Plug-in提供功能的基础上提供了另一种选择罢了，这样的话我们在Maven中使用Ant并没有脱离Maven所制定的标准，仍然受到了Maven标准的约束。而Ant在调用Maven包管理，或者使用类似功能的时候，只是类似于命令行调用了对应的命令（插件）罢了，而插件真正调用的，还是Maven的内容。
　   我觉得至少可以看出Maven与Ant非竞争对手的关系，必竟也都是一家人（都为Apache一级项目），我想还是项目粒度的问题，两人工具都有生存领域，在技术选型的时候，根据项目的特性再选择对应的工具吧。