有可能出自兼容性的考慮、或者是靈活性的考慮、又或者是考慮去除某些用戶心理上的ＦＵＤ，或者幾者兼有之，反正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.aygfsteel.com/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一級項目），我想還是項目粒度的問題，兩人工具都有生存領域，在技術選型的時候，根據項目的特性再選擇對應的工具吧。