事实是，我们处在艰难时期。 我们花了将近三个月的时间将构建机制从Ant迁移到Maven 。 如果您打算在大型项目中做同样的事情，那就是您必须安排的最短时间。 我们仍在努力解决这种迁移带来的一些附带影响，但幸运的是，它们并不是那么关键。

上下文

仅需要一点上下文，我们就有一个完整的Java EE 6系统，该系统由25个集成应用程序组成，每个应用程序平均具有3个模块（EJB，WEB等），大约有80个模块。 根据我们的Sonar分析，我们管理着接近50万行Java代码（不包括JS，CSS，JSP和JSF文件）。 构建所有内容需要15到20分钟。 这取决于服务器的状态。

决定采用Maven是开始大规模重构应用程序的先决条件，尽管使用了最新技术（Java EE 6），但多年来，这些应用程序一直遭受各种框架，设计缺陷和多种体系结构的困扰。 我们正朝着基于Java EE规范的单一架构发展，以优化依赖关系，从中长期角度降低开发成本并在Glassfish Application Server中无缝运行。

职责

由于Maven提供了灵活性，因此项目结构几乎与Ant相同。 我们在根文件夹中有一个超级pom.xml文件，该文件基本上声明了所有模块，插件，附加存储库和依赖项。 依赖性在依赖性管理中声明（使用标签<dependencyManagement>）。 这样，所有版本号都在一个地方声明。 除了超级pom.xml之外，我们还为每个集成应用程序提供一个文件夹，并且在每个文件夹中都有一个应用程序pom.xml和其他三个文件夹，每个Java EE模块（EAR，EJB，WEB）都有一个文件夹。 应用程序的pom.xml继承自超级pom，它基本上声明了组成应用程序的模块。 在模块文件夹中，我们还有一层pom文件。 这些pom文件继承自各自应用程序的pom文件，并描述其模块的特殊性。 总之，从系统整体到Java EE模块，我们共有三个pom文件级别。

结构示例类似于我们正在使用的结构。

出于开发目的，我们避免在本地部署整个应用程序。 这就是为什么我们在每个应用程序中都有一个EAR模块的原因。 这样，我们节省了仅部署正在处理的应用程序的时间。 打包以部署在服务器上时，不考虑那些应用程序EAR模块。 为了为服务器构建完整的EAR，我们有一个特殊的应用程序，其中包含EAR模块，该模块的pom文件将所有EJB和WEB模块声明为依赖项。 执行目标
这个pom.xml上的包实际上将创建超级EAR文件。

EAR模块将整个系统打包在一个部署文件中。

善良

在实施Maven之后评估项目，我们可以注意到以下好处：

Maven为简化构建背后的逻辑做出了贡献 ：现在，每个人都知道发生了什么，因为pom.xml文件比build.xml文件更容易理解。 我们的Ant文件是由
Netbeans ，因此非常大且不可读。 实际上，我们很幸运能够让它们工作这么长时间，因为很难对其进行维护。 毫无疑问，我们很快就会发现无可挽回的混乱。

Maven还有助于使所有项目相关性井井有条 ：我们从一个约100 MB的EAR软件包变成了一个约50MB的EAR软件包，减少了50％。 它有助于缩短部署时间。

我们有机会对项目进行了清理 ：在收集依赖关系以编写pom.xml文件时，我们发现不再需要某些模块。 通过模块传播的库也被删除，以支持Maven的依赖关系管理。 总而言之，我们一直说“ Maven是一场噩梦”，直到我们最终一切都井井有条，然后我们变得更加快乐和放松。 那也是大多数人所说的，因为要为特定情况找到解决方案并不容易，而且每个人都有特定的情况要处理。

简短的学习曲线 ：部署Maven之后，我们拜访了所有开发人员，重新配置了Netbeans以识别Maven项目，并向他们解释了从那时起如何进行。 他们所有人都可以立即继续他们的开发活动，并且只触发了一些支持请求。 这些电话都没有阻塞问题。 我不得不说，Netbeans为减少学习难度做出了很大的贡献，因为所有必需的目标都是直接从IDE执行的，并且不需要转到命令行，就像通常在Eclipse中发生的那样。

坏人

不幸的是，我们遇到了一些挫折：

现在，使用Maven进行构建需要更长的时间 ：由于这个原因，我们注意到开发人员的生产力下降了，最终使我们有些沮丧。 由于我们不会回滚到Ant，因此我们正在考虑JRebel对更改的代码进行动态重载，以补偿我们花费的额外时间。

我们正在使用某些在Maven中央存储库或其他地方找不到的库 ：有些是商业库，有些则太旧了。 我们还发现可用的库存在不一致之处，在运行时会引发许多异常（即Apache FOP）。 对于这些情况中的每一种，我们都必须找到不太理想的解决方法，但我们不能这么长时间保持这种状态。 我们必须安装本地Nexus存储库以解决特殊情况。 这在我们的清单中。

发生意外行为 ：尽最大的努力不足以避免应用程序中的意外行为。 我们建立了一个电子表格，列出了所有应用程序及其各自的模块。 记录所有库和模块之间的依赖关系； 描绘了项目结构； 深入细节。 为了详细说明此电子表格，我们花了几天的时间研究系统的内幕，吸收低级机制和设计决策。 所有收集的信息都用于迁移。 但是，依赖关系的重新排列以及重复项和未使用库的删除导致导航流中断，警报消息无处发出，URL路径更改以及许多其他意外事件。 不幸的是，我们无法预测这些问题，并且我们花费在修复上的时间比最初预计的要多得多。

结论

最后，我想为那些计划在中/大型项目中采用Maven的人士提供一些建议：

与最终用户交流迁移：与最终用户交流未来几天将发生的事情非常重要。 用户应注意，由于他们有责任改善自己的业务，因此我们也有义务改善自己的业务。 这意味着新功能的交付将暂时放慢速度，从而为更快发布更好的产品铺平道路。 如果他们不知道发生了什么，那么他们对问题的容忍度就会非常低，从而损害项目的声誉。

即使运行良好，也不要害怕更改 ：我们已经问过自己：如果Ant运行良好，为什么要迁移到Maven。 实际上，我们的策略是降低复杂性以简化问题的解决。 因此，我们不害怕迁移，因为预防措施也非常重要。

将整个迁移置于版本控制下，以帮助调查问题 ：一旦创建了所有pom文件并进行了版本控制，则应分别提交这些文件中的每个小更改，以便在出现意外问题时恢复更改。 它有助于找出原因。 很高兴知道Ant和Maven文件之间没有冲突。 因此，两者都可以在迁移期间留在同一个分支中，而对开发人员没有任何影响。

如果没有像Maven这样的构建系统，就不要进行大规模的重构 ：成功的重构取决于对应用程序的详细了解，采用Maven会促使您进行广泛的研究。 除此之外，该项目将变得更加干净，组织得更好。

Maven还有其他替代方法，例如Apache Ivy和Gradle ，但是，尽管应受到批评，但由于其成熟度，我们仍然推荐在替换Ant时使用Maven。 丰富的插件产品组合； 网络上的大量文档； 和丰富的IDE支持。 但是，一旦Maven到位，最好评估其他替代方案。 最初的海啸过后，其他海浪将悄悄袭来。

参考： Hildeberto博客博客中的JCG合作伙伴 Hildeberto Mendonca 将大型项目从Ant迁移到Maven 。

翻译自: https://www.javacodegeeks.com/2012/12/migrating-a-large-project-from-ant-to-maven.html