一Ant与Maven的对比
        提到Maven就不得不提到Ant，Apache Ant is a Java-based build tool.这个是Ant的指南的导言中的第一句话，有两个意思，一是指明ant是基于java语言开发的，另一个意思是指明了ant是一个构建工具。而在Maven的主页上的第一句话Maven is a software project management and comprehension tool.指出了Maven是一个软件项目管理工具，（在此段将Maven翻译成软件项目管理工具我是有疑义的，但网上查看资料都是这样翻译的，而且Project Management直译的确有项目管理的意思，晚些时候再讨论此处）。
        单纯的从字面意思上来理解，根本觉得ant与Maven是风马牛不相及的，而大家对于这两个工具为什么会划上等号，我觉得要从本质上来看Ant与Maven所做的工作了。
        Ant既然是构建工具，那ant可以做哪些事呢？编译代码、单元测试、生成文档、打包、制作安装包、混淆代码、部署等等，ant的功能可以说是非常强大的，不过整个构建过程（构建的生命周期）里需要做哪些事情，完全是需要我们自己思考定义的。
        Maven真正所做的工作其实和ant差不多，也是编译代码、单元测试、生成文档等等，那到底这两个工具间有什么异同呢？
        我想真正的差别还是体现在了思想上，在Maven的介绍页中（http://maven.apache.org/what-is-maven.html）提到Maven最初是在构建处理Jakarta Turbine项目的时候，发现这个项目的几个工程的ant构建脚本只有很细微的差别，于是Maven的作者想将构建工程标准化，对构建过程提供了一个指导性的思想，将项目构建生命周期具体化，（http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html）由此我想，为什么Maven的名称定义为Maven，可以认为Maven在思想上提供了专家级的意见的原因吧。
项目的构建生命周期被具体化后，首先是减少了对构建脚本的维护，让多个项目构建生命周期进行重用（也没啥重用的，反正用Maven生命周期都一样），让开发人员都使用这一套规范。
        当然，很多人是不吃这一套的，Maven强制开发人员接受自己定义构建标准除了让人感觉不自由、不灵活外，且担心Maven处理构建生命周期时，内部产生未知问题。还有一些小型项目，根本不需要如此完善的构建生命周期，使用Maven提供的构建生命周期，只是带来了不必要的复杂性。
        所以Maven也不是万金油，仍然需要根据项目的实际情况进行选择，对于涉及人员较多的大型项目，且在软件生命周期上与Maven的标准保持一致的情况下，就可以选择使用Maven。而对于灵活性要求较高、或者一次性的项目，使用Ant足矣。
      有可能出自兼容性的考虑、或者是灵活性的考虑、又或者是考虑去除某些用户心理上的ＦＵＤ，或者几者兼有之，反正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一级项目），我想还是项目粒度的问题，两人工具都有生存领域，在技术选型的时候，根据项目的特性再选择对应的工具吧。

一Ant与Maven的对比
        提到Maven就不得不提到Ant，Apache Ant is a Java-based build tool.这个是Ant的指南的导言中的第一句话，有两个意思，一是指明ant是基于java语言开发的，另一个意思是指明了ant是一个构建工具。而在Maven的主页上的第一句话Maven is a software project management and comprehension tool.指出了Maven是一个软件项目管理工具，（在此段将Maven翻译成软件项目管理工具我是有疑义的，但网上查看资料都是这样翻译的，而且Project Management直译的确有项目管理的意思，晚些时候再讨论此处）。
        单纯的从字面意思上来理解，根本觉得ant与Maven是风马牛不相及的，而大家对于这两个工具为什么会划上等号，我觉得要从本质上来看Ant与Maven所做的工作了。
        Ant既然是构建工具，那ant可以做哪些事呢？编译代码、单元测试、生成文档、打包、制作安装包、混淆代码、部署等等，ant的功能可以说是非常强大的，不过整个构建过程（构建的生命周期）里需要做哪些事情，完全是需要我们自己思考定义的。
        Maven真正所做的工作其实和ant差不多，也是编译代码、单元测试、生成文档等等，那到底这两个工具间有什么异同呢？
        我想真正的差别还是体现在了思想上，在Maven的介绍页中（http://maven.apache.org/what-is-maven.html）提到Maven最初是在构建处理Jakarta Turbine项目的时候，发现这个项目的几个工程的ant构建脚本只有很细微的差别，于是Maven的作者想将构建工程标准化，对构建过程提供了一个指导性的思想，将项目构建生命周期具体化，（http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html）由此我想，为什么Maven的名称定义为Maven，可以认为Maven在思想上提供了专家级的意见的原因吧。
项目的构建生命周期被具体化后，首先是减少了对构建脚本的维护，让多个项目构建生命周期进行重用（也没啥重用的，反正用Maven生命周期都一样），让开发人员都使用这一套规范。
        当然，很多人是不吃这一套的，Maven强制开发人员接受自己定义构建标准除了让人感觉不自由、不灵活外，且担心Maven处理构建生命周期时，内部产生未知问题。还有一些小型项目，根本不需要如此完善的构建生命周期，使用Maven提供的构建生命周期，只是带来了不必要的复杂性。
        所以Maven也不是万金油，仍然需要根据项目的实际情况进行选择，对于涉及人员较多的大型项目，且在软件生命周期上与Maven的标准保持一致的情况下，就可以选择使用Maven。而对于灵活性要求较高、或者一次性的项目，使用Ant足矣。

      有可能出自兼容性的考虑、或者是灵活性的考虑、又或者是考虑去除某些用户心理上的ＦＵＤ，或者几者兼有之，反正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一级项目），我想还是项目粒度的问题，两人工具都有生存领域，在技术选型的时候，根据项目的特性再选择对应的工具吧。 第一次开技术博，欢迎大家光临！