maven ant

构建工具。 用来构建项目，只需要简单的执行命令就可以。 对于个人开发有时候我们从开发到测试到最后打包可能都是一个人做，并且用一个开发工具就解决这些了，因为大多数开发工具IDE是自带打包功能的。 但是在实际的公司工作中，开发人员与测试人员、部署人员是分开的，部署人员是不会向开发人员要源代码，他们也不会打包，那么怎么部署呢？ 开发人员开发后，确认没问题，将源代码放到版本控制服务器中，并且写一个脚本，这个脚本运行就可以自动打包，然后部署人员运行这个文件打包后部署。 那么这个脚本里面需要关系到目录与加载的文件等，这时候如果每个项目用的文件都不同，目录名字千奇百怪，那么就不容易统一管理，于是构建工具出现了，它规定你的目录必须要如何定制，这样方便统一管理。 Ant是比较好的构建工具，但是脚本目录要由自己写，命令中存在依赖关系，编译，打包。 编译目录还要自己指定，maven除了指定好目录，帮你打包，同时maven有一个中央库，这个可就厉害了，一般我们做项目引用一些第三方工具包，两个项目都要用，我们为了方便，会拷贝两份工具包到项目中，无形之中磁盘占用过大，maven中央库帮你下载需要的工具包，并且只需要在pom.xml引用即可，打包时自带进去，而不用平时跟着项目跑。 ant通常脚本名为build.xml，maven的胃pom.xml 。 手打请勿复制，不在乎最佳答案，只为帮助人，混分的请绕行！

---

　　apache ant

1、ant 是程序化的，你必须明确的告诉 ant 做什么，什么时候做。你必须告诉它去编译，然后复制，然后压缩。
2、ant 没有生命周期，你必须定义目标和目标之间的依赖。你必须手工为每个目标附上一个任务序列。

apache maven

1、maven 拥有约定，因为你遵循了约定，它已经知道你的源代码在哪里。它把字节码放到 target/classes，然后在 target生成一个 jar 文件。
2、maven 是声明式的。你需要做的只是创建一个 pom.xml 文件然后将源代码放到默认的目录。maven 会帮你处理其它的事情。
3、maven 有一个生命周期，当你运行 mvn install的时候被调用。这条命令告诉 maven 执行一系列的有序的步骤，直到到达你指定的生命周期。遍历生命周期旅途中的一个影响就是，maven 运行了许多默认的插件目标，这些目标完成了像编译和创建一个 jar 文件这样的工作。

maven 以插件的形式为一些一般的项目任务提供了内置的智能。如果你想要编写运行单元测试，你需要做的只是编写测试然后放到/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/content-zh/src/test/java，添加一个对于 testng 或者 junit 的测试范围依赖，然后运行 mvn test。

如果你想要部署一个web 应用而非 jar ，你需要做的是改变你的项目类型为 war ，然后把你文档根目录置为 /usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/content-zh/src/main/webapp。当然，你可以用 ant 做这些事情，但是你将需要从零开始写这些指令。使用 ant ，你首先需要确定 junit jar 文件应该放在哪里，然后你需要创建一个包含这个 junit jar 文件的 classpath ，然后告诉 ant 它应该从哪里去找测试源代码，编写一个目标来编译测试源代码为字节码，使用 junit 来执行单元测试。没有诸如 antlibs 和 lvy 等技术的支持（即使有了这些支持技术），ant 给人感觉是自定义的程序化构建。

项目中一组高效的坚持约定的 maven pom ，相对于 ant 的配置文件，只有很少的 xml 。

maven 的另一个优点是它依靠广泛公用的 maven 插件。所有人使用 maven surefire 插件来运行单元测试，如果有人添加了一些针对新的测试框架的支持，你可以仅仅通过在你项目的 pom 中升级某个特定插件的版本来获得新的功能。

使用 maven 还是 ant 的决定不是非此即彼的，ant 在复杂的构建中还有它的位置。如果你目前的构建包含一些高度自定义的过程，或者你已经写了一些 ant 脚本通过一种明确的方法完成一个明确的过程，而这种过程不适合 maven 标准，你仍然可以在maven 中用这些脚本。作为一个 maven 的核心插件， ant 还是可用的。自定义的插件可以用 ant 来实现，maven 项目可以配置成在生命周期中运行 ant 的脚本。