sof*_*afe 33 java ant build maven
在我的新项目中,我遇到了一个复杂的基础设施,其中包含多个模块,这些模块多年来以令人不快的,不受控制的方式增长.
要说明一点:构建过程是恐怖的.有超过40个不同的,复杂的Ant文件,它们连接多次,SOA框架也生成了几个动态Ant文件.花了几天时间才真正了解所有依赖项,并最终构建整个项目而没有任何错误.
我的计划是或者是将整个项目从Ant迁移到Maven,因为计划了新组件,我希望将来能够避免这些问题,因为它现在的方式太可怕了;-)
由于我是大型项目迁移的新手,我对最佳工作流程有点困惑.涉及到许多XML文件和脚本,它们分布在非Maven目录结构中.总的来说,涉及的文件超过3000个.其中一个主要的问题是,我不知道我是否真的应该尝试迁移在已知的Maven目录结构的一切,因此风险无尽的编辑和每一个文件的重构.或者我应该保持文件夹结构不变并膨胀我的pom.xml文件,并可能遇到所有不同涉及的插件的问题？老实说,这两种方式听起来都不太具有建设性.
将此维度中的项目迁移到Maven是否有意义？特别是当SOA框架必须使用自己的Ant文件时 - 因此需要Ant和Maven的组合.简化此流程的最佳策略是什么？
谢谢你的所有建议.
Dav*_* W. 56
以下是Mavenizing Ant项目的简单快速解答:
不要做!
这不是一些反Maven的熨平板.我使用Maven,我喜欢Maven.它迫使开发人员不要做愚蠢的事情.开发人员编写构建脚本非常糟糕.他们想以这种方式做事,而不是像其他人那样做.Maven让开发人员以每个人都能理解的方式设置他们的项目.
问题是Ant允许开发人员做疯狂和疯狂的事情,你必须在Maven中完全重做.它不仅仅是目录结构.Ant允许多个构建工件.Maven只允许每pom.xml1个一个.如果您的Ant项目产生了六个不同的jar文件 - 那些jar文件包含许多相同的类,该怎么办？你将不得不为罐子创建六个Maven项目,然后再为罐子之间的共同创建六个Maven项目.
我知道,因为我做到了这一点.系统架构的负责人认为Maven是新的和好的,而Ant必须是坏的和邪恶的.构建工作并且结构良好并不重要.不,Ant必须去,而Maven就是这样.
开发人员不想这样做,所以它落在了我身上,CM.我花了六个月的时间将所有内容重写为Maven.我们有WSLD,我们有Hibernate,我们有各种框架,不知何故,我不得不重组一切以使它在Maven中工作.我不得不产生新的项目.我不得不移动目录.我必须找出新的做事方式,而不是阻止开发人员进行大量的开发.
这是地狱中最内在的圈子.
您的Ant项目如此复杂的原因之一可能与依赖项管理有关.如果你像我们现在的店铺一样,一些开发人员决定共同 开发他们自己的依赖管理系统.在看到这个依赖管理系统之后,我现在知道开发人员永远不应该写的两件事:他们自己的构建文件和依赖管理系统.
幸运的是,Ant已经存在一个名为Ivy的依赖管理系统.关于Ivy的好处是它适用于当前的Maven架构.您可以使用站点的集中式Maven存储库,Ivy可以将jar作为Maven工件部署到该存储库.
我创建了一个Ivy项目,可以自动为开发人员设置所有内容.它包含必要的设置和配置,以及一些可以取代一些标准Ant任务的宏.我曾经svn:externals将这个常春藤项目附加到主项目中.
将项目添加到当前构建系统并不太困难:
build.xml来将我们的ivy.dir项目集成到当前项目中.ivy.xml为该项目定义一个文件.<jar,并</jar>以<jar.macro和</jar.macro>.这个宏完成了标准<jar/>任务所做的一切,但它也pom.xml像Maven构建一样嵌入jar中.(Ivy有一个将ivy.xml文件转换为a的任务pom.xml).build.xml文件减少一百行.我还撕掉了所有检查和提交的东西,或ftp'd或scp'd的东西.所有这些都是为了他们的Jenkins构建系统,但是Jenkins可以在没有构建文件的任何帮助的情况下处理这个问题,谢谢.lib目录中的jar ,然后通过它们下载它们ivy.xml.总而言之,可能需要添加或更改十几行代码build.xml才能执行此操作.我已经到了可以在几个小时内将Ivy集成到一个项目中的地步 - 如果构建过程本身并没有太混乱.如果我不得不从头开始重写build.xml,可能需要两到三天时间.
使用Ivy清理了我们的Ant构建过程,并为我们提供了许多我们在Maven中可以获得的优势,而无需进行彻底的重组.
顺便说一下,这个过程最有用的工具是Beyond Compare.这使我能够快速验证新构建过程是否与旧版本兼容.
有趣的是,一旦你将你的Ant项目与Ivy集成,将它们变成Maven项目并不困难:
build.xml.您可能必须从头开始重写它,但如果没有大多数依赖管理垃圾,那就不是那么困难了.build.xml被清理,开始走动,直到它们匹配的Maven的结构目录.pom.xml并删除build.xml.1是的,我知道这不完全正确.Maven项目包括子项目和超级poms.但是,你永远不会有一个Maven项目来构建四个不同的无关罐,而这在Ant中很常见.
我过去做过类似的迁移,我对你有同样的怀疑; 但是,我选择了"保持文件夹结构完整并在POM文件中指定路径"的方式,我注意到它没有我想象的那么糟糕.
我其实要做的就是适当地设置<sourceDirectory>和<outputDirectory>也许添加一些包容和排除过滤器,但最后我想说,即使Maven的办法就是真正的约定优于配置十岁上下,让您的生活更容易,如果你按照它在何处放置文件的指令,它并没有真正使多大,如果你越不知道.
此外,在迁移时真正帮助我的东西是将模块中的Maven项目划分的可能性,我最初用它来复制Ant结构(即每个build.xml文件都有一个Maven模块),这是迁移的第一个阶段更简单,然后我更改了模块聚合,使其更有意义,更像Maven.
不确定这对你是否真的有意义,因为我没有任何生成的Ant文件,我认为这可能是你的最大问题,但我肯定会再次遵循这条道路而不是重构和移动文件到处都是Mavenize我的项目结构.