我正在开发一个相当大的项目（有许多模块，一堆外部库等），我们正在考虑从Ant切换到Maven。我理解两者之间的差异，但我不相信花时间转换项目布局，设置所有依赖关系，教导开发人员和配置管理员以“新方式”等方式做事。
Web上有很多资源描述如何从Ant迁移到Maven，但我没有发现很多说明原因的原因： - ）
答案 0 :(得分：20)
在更改构建系统之前，问问自己（和小组）为什么要改变？如果你因为Maven是“新事物”而改变，那就不要了。如果您确实看到了迁移的技术原因，请执行此操作。
一般情况下，除非有一个主要的令人信服的理由（新功能或更简单的管理），我会说保留当前项目的内容，但考虑Maven未来的项目。
答案 1 :(得分：6)
您是否阅读了“Maven，权威指南”的chapter 1？特别是，1.7 Comparing Maven with Ant进行了有趣的讨论。
我同意其他建议谨慎的答案。 Maven有很强的优势，但Ant构建过程无法做到这一点：
依赖关系管理：Ant拥有Ivy子项目，可以与Maven存储库进行交互。
约定优于配置：您也可以使用Ant来实现，只需建立规则并加以执行即可。
构建生命周期：与上述相同，您可以对每个构建所公开的任务强制执行约定。
构建逻辑重用（Maven插件）：您也可以使用macrodef和任务库在Ant中实现。
问题是，使用Maven，您可以获得开箱即用的这些功能，而使用Ant，您需要坚如磐石的构建，一套非常严格的规则以及强制执行它们的方法（例如，确保每个人在创建新子项目时都遵循惯例，他们重用现有的块而不是从头开始做任何事情。）。
就个人而言，我会看到现有流程如何解决上述问题：如何管理依赖关系，是否存在中央存储库？项目结构是否统一（当我签出一个我不知道的项目时，需要多长时间来弄清楚如何构建它）？是否有某种形式的构建逻辑重用，或者每个项目是否重新发明轮子？ 需要以下哪些功能？
然后我会尝试平衡将缺少的功能添加到现有Ant脚本的成本，以及迁移到Maven的成本（如果您不知道Maven，还包括learning it的成本）
无论如何，我建议您构建一个小型Maven原型（5到10个项目），说明构建中的常见情况。您可以使用包含很少java逻辑的虚拟项目测试很多Maven的功能（使用archetype plugin生成它们）。
答案 2 :(得分：3)
在Maven之前，我们正在检查依赖库（通常是第三方，开源变种）到源代码控制中 - 这样我们就可以确保我们的组件被编译并打包出精确的版本。
现在有了Maven，我们依靠工件存储库来保存这些版本，我们让我们的pom.xml依赖声明成为定义版本依赖关系的官方方法。事实证明，这是一种简化方法，可以使版本控制存储库（及其Hudson构建项目）中的项目组织更容易设计。我们的本地工件存储库与我们的源代码控制存储库一起处于备份策略之下。很高兴使用Maven工具去搜索并指定所需的库版本。我们还使用父pom文件来指定默认情况下其他项目poms继承的依赖项。因此，如果您希望所有项目使用相同的log4j版本，那么在父pom文件中的一个位置指定。 （但任何项目都可以随时覆盖并指定特定版本，而不是仅接受父pom中的默认版本。）
以下是成功采用Maven的秘诀：
好处是，您可以在Maven依赖管理下获得所有项目，这当然是最大的好处。
关于ant的Maven任务，你在pom.xml文件中指定所有依赖项的好处是它只涉及对现有ant build.xml文件进行适度修改以合并Maven。从ant文件的角度来看，Maven只是一种定义类路径定义的方法，随后由各种ant构建任务使用。
在定义类路径时可以使用依赖项的Maven作用域分类器，以便可以设置合适的类路径进行编译，运行单元测试，打包等。 pom中的其他定义也可以作为ant属性定义来访问。
许多现有的ant构建文件相当复杂。将这些项目转换为完整的Maven构建过程可能是一项艰巨的任务。这种使Maven管理所有依赖关系并将ant build.xml文件保留为大部分的混合方法是最实用的。
答案 3 :(得分：2)
首先，就像我相信很多人都会提到的那样，Ant和Maven并不是为了解决相同的目标。既然你说你理解了每个提供的内容，我就不会详细介绍它了，所以说Ant可以让你定义如何构建单个组件的细节，而Maven管理组件之间的依赖关系加上Maven让你定义从编译到测试的完整项目构建周期，并以编程方式部署。
我过去曾在几个项目中使用过Maven，最近我才开始在另一个项目上使用它。有很多articles on the net比较Ant和Maven，所以你可以看看这些，但根据我的经验，总是值得考虑如何改进项目。依赖管理和构建生命周期是任何大型项目的两个重要方面，Maven在这两个领域都有所帮助。如果您已经使用ant构建了一个良好的构建系统，并且您的依赖项保存在易于访问的中心位置，并且您不打算扩展构建过程以包含任何更高级的构建管理，那么也许您应该保留你有什么。
另一方面，如果您想使用像hudson这样的持续集成服务器或像nexus这样的工件库，那么将项目移动到maven可以真正帮助提高构建效率和自动化。您可能希望在这些情况下使用maven，因为使用这些类型的工具可以实现从依赖到构建到工件的完整循环，并且您将能够更好地控制构建和发布。在我目前的项目中，我们有许多模块和依赖项，就像你提到的那样。迁移到maven所以我们可以使用hudson和nexus真的很有帮助，因为我们可以将所有第三方jar放入nexus存储库，并且不再需要将它们检入版本控制或通过电子邮件发送它们。此外，构建失控，因为CM人员将构建计划作为他们有时会遵循的文档，但是使项目的这一部分（即pom.xml）定义了您应该如何构建并允许您实施它。 Maven是将所有这些东西组合在一起的粘合剂。
最后，问题是您期望项目持续多久，您的流程现在有多好，您是否要清理您的依赖项，是否要强制执行构建计划，以及是否要可以选择使用持续集成和工件管理。如果你有任何这些东西，Maven是一个很有实力的人选。