我正在开发一个相当大的项目(有许多模块,一堆外部库等),我们正在考虑从Ant切换到Maven.我理解两者之间的差异,但我不相信真的值得花时间转换项目布局,设置所有依赖项,教导开发人员和配置管理员"以新方式"做事等.
网上有很多资源描述如何从Ant迁移到Maven,但我没有发现很多说明原因的原因:-)
在更改构建系统之前,问问自己(和小组)为什么要改变?如果你因为Maven是"新事物"而改变,那就不要了.如果您确实看到了迁移的技术原因,请执行此操作.
一般来说,除非有一个主要的令人信服的理由(新功能或更简单的管理),我会说你对当前项目的所有内容保持不变,但考虑将Maven用于未来的项目.
你读过"Maven,权威指南"的第1章吗?特别是,1.7比较Maven和Ant有一个有趣的讨论.
我同意其他建议谨慎的答案.Maven有很强的优势,但Ant构建过程无法做到:
依赖管理:Ant有Ivy子项目,它可以与Maven存储库交互.
约定优于配置:您也可以使用Ant执行此操作,这只是建立规则并强制执行它们的问题.
构建生命周期:与上面相同,您可以对每个构建所公开的任务强制执行约定.
构建逻辑重用(Maven插件):您也可以使用macrodef
s和任务库在Ant中实现.
问题是,使用Maven,您可以获得开箱即用的这些功能,而使用Ant,您需要坚如磐石的构建,一套非常严格的规则以及强制执行它们的方法(例如,确保每个人都遵循他们创建新子项目时的约定,他们重用现有的块而不是从头开始做任何事情等等.
就个人而言,我会看到现有流程如何解决上述问题:如何管理依赖关系,是否存在中央存储库?项目结构是否统一(当我签出一个我不知道的项目时,需要多长时间来弄清楚如何构建它)?是否有某种形式的构建逻辑重用,或者每个项目是否重新发明轮子?需要以下哪些功能?
然后我会尝试平衡将缺少的功能添加到现有Ant脚本的成本,以及迁移到Maven的成本(如果您不知道Maven,还包括学习它的成本).
在任何情况下,我建议你构建一个小型Maven原型(5到10个项目),说明构建中的常见情况.您可以使用包含很少java逻辑的虚拟项目测试很多Maven的功能(使用archetype插件生成它们).