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

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

说到这里：构建过程是最可怕的。有40多个不同的复杂Ant文件，它们被多次连接，SOA框架还生成了几个动态Ant文件。花了几天时间才真正理解所有的依赖关系，并最终构建了整个项目，没有任何错误

我的计划是将整个项目从Ant迁移到Maven，因为已经规划了新的组件，我希望在将来避免这些问题，因为现在的情况很糟糕；-）

因为我对大型项目的迁移还不熟悉，所以我对最好的工作流有点困惑。涉及到几十个XML文件和脚本，它们分布在非Maven目录结构中。总共涉及3000多个文件。其中一个主要问题是，我不知道我是否真的应该尝试迁移已知Maven目录结构中的所有内容，从而冒着无休止地编辑和重构每个文件的风险。或者我应该保持文件夹结构不变，并使pom.xml文件膨胀，并且可能会遇到所有不同插件的问题？老实说，这两种方法听起来都不是很有建设性

---

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

---

谢谢你的建议。

我过去也做过类似的迁移，我也有过与你同样的疑虑；然而，我选择了“保持文件夹结构完整并在POM文件中指定路径”的方式，我注意到它并没有我想象的那么糟糕

实际上，我要做的是适当地设置

和

，并可能添加一些包含和排除过滤器，但最后我要说的是，即使Maven的方法实际上是常规而非配置，如果您遵循其关于文件放置位置的指示，您的生活会更轻松，如果你不这样做，这并不会让事情变得更难

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

---

我不确定这对你是否有意义，因为我没有任何生成的Ant文件，我认为这可能是你最大的问题，但我肯定会再次沿着这条路走下去，而不是重构和到处移动文件，以使我的项目结构专业化。

以下是一个简单而快速的答案，可以让Ant项目专业化：

不要这样做

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

问题是Ant允许开发人员做一些疯狂的事情，这些事情必须在Maven中完全重做。它不仅仅是目录结构。Ant允许多个构建工件。Maven只允许每个

pom.xml

1使用一个。如果您的Ant项目生成六个不同的jar文件，而这些jar文件包含许多相同的类，该怎么办？您必须仅为jar创建六个Maven项目，然后再为jar之间的公共文件创建六个Maven项目

我知道，因为我就是这么做的。系统架构负责人认为Maven是新的和好的，而Ant肯定是坏的和坏的。构建工作正常且结构良好并不重要。不，Ant必须走，Maven才是路

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

这是地狱最深处的圈子

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

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

我创建了一个常春藤项目，可以自动为开发人员设置所有内容。它包含了必要的设置和配置，以及一些可以替代一些标准Ant任务的宏。我使用了

svn:externals

将这个常春藤项目附加到主项目上

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

• 我不得不在

  build.xml

  中添加几行代码，以便将我们的

  ivy.dir

  项目集成到当前项目中
• 我必须为那个项目定义一个

  ivy.xml

  文件
• 我换了一些