事实是,我们处在艰难时期。 我们花了将近三个月的时间将构建机制从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文件。
善良
在实施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