我正在开展一个非常庞大的项目（包括许多模块和一些外部库等），我们现在正在考虑从Ant转换到Maven。我理解两者之间的区别，但我并不确定值得花时间来转换项目布局、设置所有依赖项、教授开发人员和配置管理人员使用“新方法”等。
网络上有很多关于如何从Ant迁移到Maven的资源，但我没有找到很多说明为什么要这样做的资源 :-)
4个回答
21
在更改构建系统之前，问问自己（和团队）为什么要进行更改？如果只是因为Maven是“新事物”，那就不要更改。如果您真的看到了迁移的技术原因，请进行更改。
通常情况下，除非有重大的强制性原因（新功能或更简单的管理），我会建议在当前项目中继续使用现有的系统，但在未来的项目中考虑使用Maven。
通常情况下，除非有重大的强制性原因（新功能或更简单的管理），我会建议在当前项目中继续使用现有的系统，但在未来的项目中考虑使用Maven。
- lacqui
1
3"Maven的理念是实现更加简单化的管理和标准化的工作流程。仅仅单独考虑依赖管理，就值得进行迁移。" - Frederic Morin
7
你是否阅读过《Maven权威指南》的第一章？特别是1.7 Maven与Ant的比较，其中有一个有趣的讨论。
我同意其他回答中提醒谨慎的观点。 Maven 有其优点，但没有什么是 Ant 构建流程无法完成的：
依赖管理：Ant 有 Ivy 子项目，可以与 Maven 仓库进行交互。
约定优于配置：你也可以在 Ant 中实现这一点，只需要确立规则并加以执行即可。
构建生命周期：同上，你可以通过规定每个构建所公开的任务来执行约定。
构建逻辑复用（Maven 插件）：你也可以使用
macrodef和任务库在 Ant 中实现。
就我个人而言，我会看看现有的流程如何解决上述问题：依赖项是如何管理的？是否有一个中央仓库？项目结构是否统一（当我检出一个我不熟悉的项目时，需要多长时间才能弄清楚如何构建它）？是否存在某种形式的构建逻辑复用，还是每个项目都要重新发明轮子？哪些功能是必需的？
然后，我会尝试平衡将缺失的功能添加到现有的Ant脚本的成本与迁移到Maven的成本之间的差异（如果您不了解Maven，则还包括学习它的成本）。
无论如何，我建议您构建一个小的Maven原型（5到10个项目），展示您构建中的常见情况。您可以使用包含少量Java逻辑的虚拟项目来测试许多Maven功能（使用archetype插件生成它们）。
- Olivier
2
我很同意这一点。在许多情况下，当您只需要依赖管理时，将Maven或Ivy任务添加到现有的Ant脚本中就足够了。 - sal
1我同意所有的观点，但是“约定优于配置”有时候会让人感到沮丧，特别是对于那些正在学习如何使用它并不知道“约定”是什么的人来说。 - Jin Kim
3
在使用Maven之前，我们将依赖库（通常是第三方的开源库）检入到源代码控制中，以确保我们的组件编译并与预期的版本一起打包。
现在有了Maven，我们依赖于存储库来保存这些版本，并让我们的pom.xml依赖声明成为定义版本依赖关系的官方手段。这被证明是一种简化的方法，使得在版本控制存储库（及其Hudson构建项目）中组织项目变得更加容易。我们的本地存储库和源代码控制存储库一样都在备份策略下。使用Maven工具去搜索和指定所需的库版本很方便。我们还使用父POM文件来指定其他项目POM默认继承的依赖项。因此，如果您希望所有项目使用相同的log4j版本，则在父POM文件中的一个位置指定即可。（但是任何项目都可以随时覆盖并指定特定版本，而不仅仅接受来自父POM的默认值。）
以下是成功采用Maven的秘诀：
- 对于新的绿色项目，请使用Maven项目构建方法 - 修改现有的使用ant build.xml文件的遗留项目，以整合Maven任务以管理依赖项（混合方法）
好处是您可以将所有项目都纳入Maven依赖管理，这当然是它最大的好处。
使用Maven任务来指定pom.xml文件中的所有依赖项的美妙之处在于，只需对现有的ant build.xml文件进行适度的修改即可将其整合到Maven中。从ant文件的角度来看，Maven只是定义类路径定义的一种手段，随后由各种ant构建任务使用。
在定义类路径时可以利用依赖项的Maven范围分类器，以便为编译、运行单元测试、打包等设置适当的类路径。 POM中的其他定义也可以作为ant属性定义访问。
许多现有的ant build文件非常复杂。将这些项目转换为完整的Maven构建过程可能是一个艰巨的任务。因此，采用混合方法，让Maven管理所有依赖项，并保留大部分ant build.xml文件是最实用的方法。
现在有了Maven，我们依赖于存储库来保存这些版本，并让我们的pom.xml依赖声明成为定义版本依赖关系的官方手段。这被证明是一种简化的方法，使得在版本控制存储库（及其Hudson构建项目）中组织项目变得更加容易。我们的本地存储库和源代码控制存储库一样都在备份策略下。使用Maven工具去搜索和指定所需的库版本很方便。我们还使用父POM文件来指定其他项目POM默认继承的依赖项。因此，如果您希望所有项目使用相同的log4j版本，则在父POM文件中的一个位置指定即可。（但是任何项目都可以随时覆盖并指定特定版本，而不仅仅接受来自父POM的默认值。）
以下是成功采用Maven的秘诀：
- 对于新的绿色项目，请使用Maven项目构建方法 - 修改现有的使用ant build.xml文件的遗留项目，以整合Maven任务以管理依赖项（混合方法）
好处是您可以将所有项目都纳入Maven依赖管理，这当然是它最大的好处。
使用Maven任务来指定pom.xml文件中的所有依赖项的美妙之处在于，只需对现有的ant build.xml文件进行适度的修改即可将其整合到Maven中。从ant文件的角度来看，Maven只是定义类路径定义的一种手段，随后由各种ant构建任务使用。
在定义类路径时可以利用依赖项的Maven范围分类器，以便为编译、运行单元测试、打包等设置适当的类路径。 POM中的其他定义也可以作为ant属性定义访问。
许多现有的ant build文件非常复杂。将这些项目转换为完整的Maven构建过程可能是一个艰巨的任务。因此，采用混合方法，让Maven管理所有依赖项，并保留大部分ant build.xml文件是最实用的方法。
- RogerV
2
首先，就像我相信很多人会提到的那样，Ant和Maven并不是用来解决相同目标的。由于你说你理解每个工具的提供内容，所以我不会详细介绍它们的细节，简单地说，Ant允许您定义如何构建单个组件的细节，而Maven管理组件之间的依赖关系，并允许您以编程方式定义完整的项目构建周期，从编译、测试到部署。
我过去在几个项目中使用过Maven，并最近开始在另一个项目中使用它。有很多{{link1：网上的文章}}比较Ant和Maven，所以你可以看看这些文章，但从我的经验来看，考虑如何改进项目总是值得的。依赖管理和构建生命周期是任何大型项目的两个重要方面，而Maven在这两个方面都有帮助。如果您已经有了一个使用Ant的良好构建系统，并且您的依赖项存储在易于访问的中央位置，并且您不计划扩展您的构建过程以包括任何更高级别的构建管理，则可能应该保留现有的构建系统。
另一方面，如果你想使用像Hudson这样的持续集成服务器或Nexus这样的构件库，那么将你的项目迁移到Maven可以真正帮助提高构建效率和自动化程度。在这些情况下，你可能会喜欢Maven，因为使用这些类型的工具可以实现从依赖项到构建再到构件的完整周期，并且你将能够更好地控制你的构建和发布。在我目前的项目中，我们有许多模块和依赖项，就像你提到的那样。迁移到Maven，这样我们就可以使用Hudson和Nexus，确实有很大帮助，因为我们可以将所有这些第三方jar包放入Nexus存储库中，不再需要将它们检入版本控制或通过电子邮件发送。此外，由于CM人员拥有一个作为文档的构建计划，他们有时会遵循这个计划，但是将其作为你的项目的一部分（即pom.xml）定义如何构建并让你强制执行。Maven是将所有这些东西粘合在一起的胶水。
我过去在几个项目中使用过Maven，并最近开始在另一个项目中使用它。有很多{{link1：网上的文章}}比较Ant和Maven，所以你可以看看这些文章，但从我的经验来看，考虑如何改进项目总是值得的。依赖管理和构建生命周期是任何大型项目的两个重要方面，而Maven在这两个方面都有帮助。如果您已经有了一个使用Ant的良好构建系统，并且您的依赖项存储在易于访问的中央位置，并且您不计划扩展您的构建过程以包括任何更高级别的构建管理，则可能应该保留现有的构建系统。
另一方面，如果你想使用像Hudson这样的持续集成服务器或Nexus这样的构件库，那么将你的项目迁移到Maven可以真正帮助提高构建效率和自动化程度。在这些情况下，你可能会喜欢Maven，因为使用这些类型的工具可以实现从依赖项到构建再到构件的完整周期，并且你将能够更好地控制你的构建和发布。在我目前的项目中，我们有许多模块和依赖项，就像你提到的那样。迁移到Maven，这样我们就可以使用Hudson和Nexus，确实有很大帮助，因为我们可以将所有这些第三方jar包放入Nexus存储库中，不再需要将它们检入版本控制或通过电子邮件发送。此外，由于CM人员拥有一个作为文档的构建计划，他们有时会遵循这个计划，但是将其作为你的项目的一部分（即pom.xml）定义如何构建并让你强制执行。Maven是将所有这些东西粘合在一起的胶水。
最终，这取决于你期望项目持续多长时间，你现在的流程有多好，你是否想清理你的依赖项，你是否想强制执行你的构建计划，以及你是否想有使用持续集成和构件管理的选项。如果你需要这些功能中的任何一项，Maven是一个很好的选择。
- John
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接