以下是对 Mavenizing a Ant 项目的简单而快速的答案：
别这样！
这不是一些反Maven的熨平板。我使用Maven，我喜欢Maven。它迫使开发人员不要做愚蠢的事情。开发人员在编写构建脚本方面很糟糕。他们想以这种方式做事，而不是其他人那样做事。Maven让开发人员以每个人都能理解的方式设置他们的项目。
问题在于，Ant允许开发人员做疯狂而疯狂的事情，你必须在Maven中完全重做。它不仅仅是目录结构。Ant 允许多个构建工件。Maven 只允许每 1 个。如果您的 Ant 项目生成了六个不同的 jar 文件，并且这些 jar 文件包含许多相同的类，该怎么办？您必须仅为jar创建六个Maven项目，然后为jar之间共有的文件创建另外六个。pom.xml
我知道，因为我正是这样做的。系统架构的负责人认为Maven是新的和好的，而Ant必须是坏的和邪恶的。构建是否有效且结构良好并不重要。不，蚂蚁必须走，而Maven是路。
开发人员不想这样做，所以它落在了我身上，CM。我花了六个月的时间把所有东西都重写成Maven。我们有WSLD，我们有Hibernate，我们有各种框架，不知何故，我不得不重组所有内容才能使其在Maven中工作。我不得不催生新的项目。我不得不四处移动目录。我必须找出新的做事方式，同时又不妨碍开发人员进行大量的开发。
这是地狱最核心的圈子。
Ant 项目如此复杂的原因之一可能与依赖关系管理有关。如果你像我们现在的商店一样，一些开发者决定一起开发自己的依赖管理系统。在看到这个依赖管理系统之后，我现在知道开发人员永远不应该写两件事：他们自己的构建文件和依赖管理系统。
幸运的是，蚂蚁已经存在一个名为Ivy的依赖管理系统。Ivy的好处在于它与当前的Maven架构一起工作。您可以使用站点的集中式 Maven 存储库，Ivy 可以将 jar 作为 Maven 工件部署到该存储库。
我创建了一个常春藤项目，它自动为开发人员设置所有内容。它包含必要的设置和配置，以及一些可以取代一些标准 Ant 任务的宏。我曾经把这个常春藤项目附加到主项目上。svn:externals
将项目添加到当前的构建系统中并不难：
- 我不得不在 中添加几行，以将我们的项目集成到当前项目中。
build.xmlivy.dir
- 我必须为该项目定义一个文件。
ivy.xml
- 我将 和 的任何实例更改为 和 。这个宏完成了标准任务所做的一切，但它也像Maven builds一样将嵌入到jar中（Ivy有一个将文件转换为）的任务。
<jar</jar><jar.macro</jar.macro><jar/>pom.xmlivy.xmlpom.xml
- 我撕掉了其他开发人员添加的所有旧的依赖管理废话。这可能会将文件减少一百行。我还撕掉了所有做结账和提交的东西，或者ftp'd或scp'd的东西。所有这些东西都是为他们的Jenkins构建系统准备的，但是Jenkins可以在没有任何构建文件帮助的情况下处理这个问题，谢谢。
build.xml
- 添加几行以集成常春藤。最简单的方法是删除目录中的 jar，然后通过 下载它们。总而言之，可能需要添加或更改十几行代码才能执行此操作。
libivy.xmlbuild.xml
我到了这样一个地步，我可以在几个小时内将Ivy集成到一个项目中 - 如果构建过程本身不是太混乱的话。如果我必须从头开始重写构建.xml，我可能需要两到三天的时间。
使用Ivy清理了我们的蚂蚁构建过程，并允许我们在Maven中拥有许多优势，而无需进行彻底的重组。
顺便说一句，此过程最有用的工具是超越比较。这使我能够快速验证新的构建过程是否与旧的构建过程兼容。
无论如何，搬到Maven...
有趣的是，一旦你将Ant项目与Ivy集成在一起，将它们变成Maven项目就不那么困难了：
- 清理 .您可能必须从头开始重写它，但是如果没有大多数依赖项管理垃圾，它就不那么困难了。
build.xml
- 清理后，开始移动目录，直到它们与Maven的结构匹配。
build.xml
- 更改源以匹配新的目录结构。您可能有一个 WAR，其中包含位于非标准位置的 *css 文件，并且代码是硬连线的，以便将这些文件放在该目录中。您可能需要更改 Java 代码以匹配新的目录结构。
- 将构建多个项目的 Ant 项目分解为单独的 Ant 项目，每个项目构建一个工件。
- 添加 和 删除 .
pom.xmlbuild.xml
1 是的，我知道这并不完全正确。有带有子项目和超级poms的Maven项目。但是，你永远不会有一个Maven项目来构建四个不同的不相关的jar，而这在Ant中很常见。
