在我的新项目中，我遇到了一个复杂的基础设施，其中包含多个模块，这些模块多年来以令人不快的，不受控制的方式发展。
要说明一点：构建过程是恐怖的。有超过40个不同的，复杂的Ant文件，它们连接多次，SOA框架也生成了几个动态Ant文件。花了几天时间才真正了解所有依赖项，并最终构建整个项目而没有任何错误。
我的计划是或者是将整个项目从Ant迁移到Maven，因为计划了新的组件，我希望将来能够避免这些问题，因为它现在的方式太可怕了;-)
由于我不熟悉大型项目的迁移，我对最佳工作流程有点困惑。涉及到许多XML文件和脚本，它们分布在非Maven目录结构中。总的来说，涉及的文件超过3000个。其中一个主要问题是我不知道我是否真的应该尝试迁移已知Maven目录结构中的所有内容，因此冒着无休止的编辑和重构每个文件的风险。或者我应该保持文件夹结构不变并膨胀我的pom.xml文件，并可能遇到所有不同涉及的插件的问题？老实说，这两种方式听起来都不太具有建设性。
将此维度中的项目迁移到Maven是否有意义？特别是当SOA框架必须使用自己的Ant文件时 - 因此需要Ant和Maven的组合。什么是简化这一过程的最佳策略？
感谢所有建议。
答案 0 :(得分：56)
以下是Mavenizing Ant项目的简单快速解答：
不要做！
这不是一些反Maven的熨平板。我使用Maven，我喜欢Maven。它迫使开发人员不要做愚蠢的事情。开发人员编写构建脚本非常糟糕。他们希望以这种方式做事，而不是像其他人那样做。 Maven让开发人员以每个人都能理解的方式设置他们的项目。
问题是Ant允许开发人员做疯狂和疯狂的事情，你必须在Maven中完全重做。它不仅仅是目录结构。 Ant允许多个构建工件。 Maven只允许每pom.xml 1 一个。如果您的Ant项目产生了六个不同的jar文件 - 那些jar文件包含许多相同的类，该怎么办？您必须为罐子创建六个Maven项目，然后再为罐子之间共同创建六个文件。
我知道，因为我做到了这一点。系统架构的负责人认为Maven是新的和好的，而Ant必须是坏的和邪恶的。构建工作并且结构良好并不重要。不，Ant必须去，Maven就是这样。
开发人员并不想这样做，所以它落在了我身上，CM。我花了六个月的时间将所有内容重写为Maven。我们有WSLD，我们有Hibernate，我们有各种框架，不知何故，我不得不重组一切以使它在Maven中工作。我不得不产生新的项目。我不得不移动目录。我必须弄清楚新的做事方式，所有这些都不会阻止开发人员进行大量的开发。
这是地狱中最内在的圈子。
Ant项目如此复杂的原因之一可能与依赖项管理有关。如果你像我们当前的商店一样，一些开发人员决定 hack together 开发他们自己的依赖管理系统。在看到这个依赖管理系统之后，我现在知道开发人员永远不应该写的两件事：他们自己的构建文件和依赖管理系统。
幸运的是，已经存在一个名为Ivy的Ant的依赖管理系统。关于Ivy的好处是它适用于当前的Maven架构。您可以使用站点的集中式Maven存储库，Ivy可以将jar作为Maven工件部署到该存储库。
我创建了一个Ivy项目，可以自动为开发人员设置所有内容。它包含必要的设置和配置，以及一些可以取代一些标准Ant任务的宏。我使用svn:externals将这个常春藤项目附加到主项目中。
将项目添加到当前构建系统中并不困难：
build.xml中添加几行，以便将我们的ivy.dir项目集成到当前项目中。ivy.xml文件。<jar和</jar>的任何实例更改为<jar.macro和</jar.macro>。这个宏完成了标准<jar/>任务所做的所有事情，但它也像Maven构建那样将pom.xml嵌入到jar中。 （常春藤有一项将ivy.xml文件转换为pom.xml）的任务。build.xml文件减少一百行。我还撕掉了所有检查和提交的东西，或者ftp或者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项目包含子项目和 super poms 。但是，你永远不会有一个Maven项目来构建四个不同的无关罐子，而这在Ant中很常见。
答案 1 :(得分：8)
我过去曾做过类似的迁移，我对此有过同样的怀疑;但是，我选择了“保持文件夹结构完整并指定POM文件中的路径”的方式，我注意到它没有我想象的那么糟糕。
我实际需要做的是适当地设置<sourceDirectory>和<outputDirectory>并且可能添加一些包含和排除过滤器，但最后我会说，即使Maven的方式确实如此如果你遵循其关于放置文件的位置的指令，它就会使你的生活变得更容易，如果不这样做，它就不会让它变得更难
此外，在迁移时真正帮助我的东西是将模块中的Maven项目划分的可能性，我最初用来复制Ant结构（即每个build.xml文件都有一个Maven模块）进入第一阶段迁移的简单性，然后我改变了模块聚合，使其更有意义，更像Maven。
不确定这对你是否真的有意义，因为我没有任何生成的Ant文件，我认为这可能是你的最大问题，但我肯定会再次遵循这条道路而不是重构和移动文件无处不在我的项目结构。