顺德网站建设效果,aspx网站模板,普陀网站制作,分享类网站怎么做maven项目 ant事实是我们处在艰难时期。 我们花了将近三个月的时间将构建机制从Ant迁移到Maven 。 如果您打算在大型项目中进行同样的安排#xff0c;那是您必须安排的最短时间。 我们仍在努力解决这种迁移带来的一些附带影响#xff0c;但幸运的是#xff0c;它们并不是那么… maven项目 ant 事实是我们处在艰难时期。 我们花了将近三个月的时间将构建机制从Ant迁移到Maven 。 如果您打算在大型项目中进行同样的安排那是您必须安排的最短时间。 我们仍在努力解决这种迁移带来的一些附带影响但幸运的是它们并不是那么关键。 上下文 仅需要一点上下文我们就有一个由25个集成应用程序组成的完整Java EE 6系统每个应用程序平均具有3个模块EJBWEB等达到约80个模块。 根据我们的Sonar分析我们管理着接近500K行的Java代码不包括JSCSSJSP和JSF文件。 构建所有内容需要15到20分钟。 这取决于服务器的心情。 决定采用Maven是开始大规模重构应用程序的先决条件尽管使用了最新技术Java EE 6但多年来这些应用程序遭受了多种框架设计缺陷和多种体系结构的困扰。 我们正在朝着建立在Java EE规范基础上的单一体系结构的方向发展以优化依赖关系从中长期角度降低开发成本并在Glassfish Application Server中无缝运行。 职责 由于Maven提供了灵活性因此项目结构几乎与Ant相同。 我们在根文件夹中有一个超级pom.xml文件该文件基本上声明了所有模块插件附加存储库和依赖项。 依赖关系在依赖关系管理中声明使用标记dependencyManagement。 这样所有版本号都在一个地方声明。 除了超级pom.xml之外我们还为每个集成应用程序提供一个文件夹并且在每个文件夹中都有一个应用程序pom.xml和其他三个文件夹每个Java EE模块EAREJBWEB都有一个文件夹。 应用程序的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的软件包减少了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.htmlmaven项目 ant
