将复杂项目从 Ant 迁移到 Maven - 如何处理不寻常的文件夹结构？

Posted 2023-03-30

【中文标题】将复杂项目从 Ant 迁移到 Maven - 如何处理不寻常的文件夹结构？

【英文标题】：Migrating complex project from Ant to Maven - How to handle unusual folder structures?

【发布时间】：2013-06-18 17:29:31

【问题描述】：

在我的新项目中，我面临一个复杂的基础架构，其中包含多个模块，这些模块多年来以令人不快、不受控制的方式增长。

言归正传：构建过程令人恐惧。有 40 多个不同的复杂 Ant 文件，它们多次连接，SOA 框架还生成多个动态 Ant 文件。花了几天时间才真正了解所有的依赖关系，并最终构建了整个项目而没有任何错误。

我的计划是或现在将整个项目从 Ant 迁移到 Maven，因为计划了新组件，我希望将来避免这些问题，因为它现在的方式太可怕了 ;-)

由于我是迁移大型项目的新手，我对最佳工作流程有点困惑。涉及的 XML 文件和脚本有几十个，分布在非 Maven 目录结构中。总体而言，涉及的文件超过 3000 个。主要问题之一是我不知道我是否真的应该尝试迁移已知 Maven 目录结构中的所有内容，因此冒着对每个文件进行无休止的编辑和重构的风险。或者我应该保持文件夹结构原样并膨胀我的 pom.xml 文件，并且可能会遇到所有不同涉及的插件的问题？老实说，这两种方式听起来都不太有建设性。

将这个维度的项目迁移到 Maven 是否有意义？尤其是当 SOA 框架必须使用自己的 Ant 文件时——因此需要将 Ant 和 Maven 结合起来。简化此过程的最佳策略是什么？

感谢所有建议。

【问题讨论】：

“将这个维度的项目迁移到 Maven 是否有意义？”取决于你的目标是什么。一般来说，我倾向于“不”，特别是因为“动态生成的 Ant 文件”的恐怖。我将再也不会使用 Ant 开始这样的项目 - 但转换现有项目是完全不同的一杯茶。

***.com/questions/8465656/…

【参考方案1】：

以下是 Mavenizing 一个 Ant 项目的简单快速的答案：

不要这样做！

这不是一些反 Maven 的熨平板。我使用 Maven，我喜欢 Maven。它迫使开发人员不要做愚蠢的事情。开发人员在编写构建脚本方面很糟糕。他们想以这种方式做事，而不是像其他人那样做。 Maven 让开发人员以每个人都能理解的方式设置他们的项目。

问题在于 Ant 允许开发人员做一些你必须在 Maven 中完全重做的疯狂而疯狂的事情。它不仅仅是目录结构。 Ant 允许多个构建工件。 Maven 只允许每个pom.xml¹ 一个。如果您的 Ant 项目产生了六个不同的 jar 文件——并且这些 jar 文件包含许多相同的类，该怎么办？您必须为 jars 创建六个 Maven 项目，然后为 jars 之间的共同文件创建另外六个。

我知道，因为我正是这样做的。系统架构负责人认为 Maven 是新的和好的，而 Ant 必须是坏的和邪恶的。构建是否有效并且结构良好并不重要。不，Ant 必须走，而 Maven 是路。

开发人员不想这样做，所以它落到了我这个 CM 身上。我花了六个月的时间将所有东西都改写成 Maven。我们有 WSLD，我们有 Hibernate，我们有各种框架，而且不知何故，我不得不重组一切，让它在 Maven 中工作。我不得不产生新的项目。我不得不四处移动目录。我必须找出新的做事方式，同时又不能阻止开发人员进行大量开发。

这是地狱的最内圈。

您的 Ant 项目如此复杂的原因之一可能与依赖管理有关。如果您像我们现在的商店一样，一些开发人员决定hack together 开发他们自己的依赖管理系统。在看到这个依赖管理系统之后，我现在知道了开发人员不应该写的两件事：他们自己的构建文件和依赖管理系统。

幸运的是，Ant 已有一个名为Ivy 的依赖管理系统。 Ivy 的优点在于它适用于当前的 Maven 架构。您可以使用站点的集中式 Maven 存储库，Ivy 可以将 jar 作为 Maven 工件部署到该存储库。

我创建了一个 Ivy 项目，它会自动为开发人员设置所有内容。它包含必要的设置和配置，以及一些可以替代一些标准 Ant 任务的宏。我使用svn:externals 将这个 Ivy 项目附加到主项目。

将项目添加到当前的构建系统中并不太难：

我必须在build.xml 中添加几行，以将我们的ivy.dir 项目集成到当前项目中。 我必须为该项目定义一个ivy.xml 文件。 我将<jar 和</jar> 的任何实例更改为<jar.macro 和</jar.macro>。这个宏完成了标准 <jar/> 任务所做的一切，但它也像 Maven 构建一样将 pom.xml 嵌入到 jar 中。 （Ivy 的任务是将ivy.xml 文件转换为pom.xml）。 我删除了其他开发人员添加的所有旧依赖管理废话。这可以将build.xml 文件减少一百行。我还撕掉了所有检查和提交的东西，或者 ftp'​​d 或 scp'd 的东西。所有这些东西都是为了他们的 Jenkins 构建系统，但是 Jenkins 可以在没有任何构建文件帮助的情况下处理这个问题，谢谢。 添加几行来集成 Ivy。最简单的方法是删除lib 目录中的jar，然后通过ivy.xml 下载它们。总之，可能需要在build.xml 中添加或更改十几行代码才能做到这一点。

我可以在几个小时内将 Ivy 集成到一个项目中——如果构建过程本身不是太混乱的话。如果我必须从头开始重写 build.xml，可能需要两三天。

使用 Ivy 清理了我们的 Ant 构建过程，让我们无需进行完全重组即可获得在 Maven 中拥有的许多优势。

顺便说一下，这个过程最有用的工具是Beyond Compare。这让我能够快速验证新的构建过程是否与旧的兼容。

---

无论如何都要迁移到 Maven...

有趣的是，一旦您将 Ant 项目与 Ivy 集成，将它们转换为 Maven 项目并不难：

清理build.xml 中的逻辑。您可能必须从头开始重写它，但如果没有大部分依赖管理垃圾，这并不是那么困难。 清理完build.xml 后，开始移动目录，直到它们与 Maven 的结构相匹配。 更改源以匹配新目录结构。您可能有一个在非标准位置包含 *css 文件的 WAR，并且代码被硬连线以期望这些文件位于该目录中。您可能需要更改 Java 代码以匹配新的目录结构。 将构建多个项目的 Ant 项目拆分为单独的 Ant 项目，每个项目构建一个工件。 添加pom.xml 并删除build.xml。

---

¹ 是的，我知道这并不完全正确。有子项目和 super pom 的 Maven 项目。但是，您永远不会有一个构建四个不同的不相关 jar 的 Maven 项目，而这在 Ant 中很常见。

【讨论】：

我意识到这是一篇非常古老的帖子，但想了解您使用的规模。在这 6 个月的重写期间，您从事的项目的大致数量是多少？

【参考方案2】：

我过去做过类似的迁移，我也有同样的疑问；但是，我选择了“保持文件夹结构完整并在 POM 文件中指定路径”的方式，我发现它并没有我想象的那么糟糕。

我实际上需要做的是适当地设置<sourceDirectory> 和<outputDirectory> 并可能添加一些包含和排除过滤器，但最后我想说的是，即使Maven 的方式真的是约定俗成的如果您遵循其关于文件放置位置的指示，那么配置会让您的生活更轻松，但如果您不这样做，它并不会真正让事情变得更难。

此外，在迁移时真正帮助我的是可以将 Maven 项目划分为模块，我最初用它来复制 Ant 结构（即，每个 build.xml 文件都有一个 Maven 模块）进行第一阶段迁移更简单，然后我更改了模块聚合以使其更有意义和更像 Maven。

不确定这对你是否真的有意义，因为我没有任何生成的 Ant 文件，我发现这可能是你最大的问题，但我肯定会再次走这条路，而不是重构和移动文件到处 Mavenize 我的项目结构。