这是 Mavenizing 一个 Ant 项目的简单快速的答案：
不要这样做！
这不是一些反 Maven 熨平板。我使用 Maven，我喜欢 Maven。它迫使开发人员不要做愚蠢的事情。开发人员在编写构建脚本方面很糟糕。他们想以这种方式做事，而不是像其他人那样做。Maven 使开发人员以每个人都能理解的方式设置他们的项目。
问题是 Ant 允许开发人员做一些你必须在 Maven 中完全重做的疯狂而疯狂的事情。它不仅仅是目录结构。Ant 允许多个构建工件。Maven 只允许一个 per pom.xml1。如果您的 Ant 项目产生了六个不同的 jar 文件——并且这些 jar 文件包含许多相同的类，该怎么办？您必须为 jars 创建六个 Maven 项目，然后为 jars 之间的共同文件创建另外六个。
我知道，因为我正是这样做的。系统架构负责人认为 Maven 是新的和好的，而 Ant 必须是坏的和邪恶的。构建是否有效并且结构良好并不重要。不，Ant 必须走，而 Maven 是路。
开发人员不想这样做，所以它落到了我这个 CM 身上。我花了六个月的时间将所有东西都改写成 Maven。我们有 WSLD，我们有 Hibernate，我们有各种框架，而且不知何故，我不得不重组一切，让它在 Maven 中工作。我不得不产生新的项目。我不得不四处移动目录。我必须想出新的做事方式，而这一切都不能阻止开发人员进行大量的开发。
这是地狱的最内圈。
Ant 项目如此复杂的原因之一可能与依赖管理有关。如果您像我们现在的商店一样，一些开发人员决定共同 开发自己的依赖管理系统。在看到这个依赖管理系统之后，我现在知道了开发人员不应该写的两件事：他们自己的构建文件和依赖管理系统。
幸运的是，Ant 已有一个名为Ivy的依赖管理系统。Ivy 的优点在于它适用于当前的 Maven 架构。您可以使用站点的集中式 Maven 存储库，并且 Ivy 可以将 jar 作为 Maven 工件部署到该存储库。
我创建了一个 Ivy 项目，它会自动为开发人员设置一切。它包含必要的设置和配置，以及一些可以替代一些标准 Ant 任务的宏。我曾经svn:externals将这个 Ivy 项目附加到主项目中。
将项目添加到当前的构建系统中并不太难：
- 我必须在中添加几行
build.xml以将我们的ivy.dir项目集成到当前项目中。
- 我必须
ivy.xml为该项目定义一个文件。
- 我将and的任何实例更改为
<jarand 。这个宏完成了标准任务所做的一切，但它也像 Maven 构建一样将 jar 嵌入到 jar 中。（Ivy 的任务是将文件转换为.</jar><jar.macro</jar.macro><jar/>pom.xmlivy.xmlpom.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.
1是的，我知道这并不完全正确。有带有子项目和超级 pom的 Maven 项目。但是，您永远不会有一个构建四个不同的不相关 jar 的 Maven 项目，而这在 Ant 中很常见。