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

问题描述

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

In my new project I am confronted with a complex infrastructure with several modules which have grown over the years in an unpleasant, uncontrolled way.

说到点子上:构建过程是恐怖的.有 40 多个不同的、复杂的 Ant 文件，它们被多次连接，SOA 框架还生成了几个动态 Ant 文件.花了几天的时间才真正理解了所有依赖项，并最终构建了没有任何错误的整个项目.

To come to the point: The build process is the horror. There are over 40 different, complex Ant files, which are connected multiple times and the SOA framework also generates several dynamic Ant files. It took a few days to really understand all the dependencies and to finally build the whole project without any errors.

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

My plan was or is to migrate the whole project from Ant to Maven, since new components are planned and I would like to avoid these problems in the future and well, because it is just horrible the way it is now ;-)

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

Since I am new to the migration of bigger projects, I am a little bit confused about the best workflow. There are dozens of XML files and scripts involved, which are distributed in a non-Maven directory structure. Overall there are over 3000 files involved. One of the main problems is that I don't know if I really should try to migrate everything in the known Maven directory structure and therefore risk endless editing and refactoring of every single file. Or should I keep the folder structure as it is and bloat my pom.xml files and possibly run into problems with all the different involved plugins? Honestly, both ways don't sound quite constructive.

把这个维度的项目迁移到Maven还有意义吗?特别是当 SOA 框架必须使用自己的 Ant 文件时——因此需要结合使用 Ant 和 Maven.简化此过程的最佳策略是什么?

Does it even make sense to migrate a project in this dimension to Maven? Especially when the SOA framework must use its own Ant files - therefore a combination of Ant and Maven would be necessary. What would be the best strategy to simplify this process?

感谢所有建议.

推荐答案

以下是对 Ant 项目进行 Mavenizing 的简单快速答案:

Here's a simple and quick answer to Mavenizing an Ant project:

不要这样做！

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

This is not some anti-Maven screed. I use Maven, and I like Maven. It forces developers not to do stupid things. Developers are terrible at writing build scripts. They want to do things this way and not the way everyone else does. Maven makes developers setup their projects in a way that everyone can understand.

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

The problem is that Ant allows developers to do wild and crazy things that you have to completely redo in Maven. It's more than just the directory structure. Ant allows for multiple build artifacts. Maven only allows for one per pom.xml. What if your Ant project produces a half dozen different jar files -- and those jar files contain many of the same classes? You'll have to create a half dozen Maven projects just for the jars, and then another half dozen for the files that are in common between the jars.

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

I know because I did exactly this. The head of System Architecture decided that Maven is new and good while Ant must be bad and Evil. It didn't matter that the builds worked and were well structured. No, Ant must go, and Maven is the way.

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

The developers didn't want to do this, so it fell to me, the CM. I spent six months rewriting everything into Maven. We had WSLD, we had Hibernate, we had various frameworks, and somehow, I had to restructure everything to get it to work in Maven. I had to spawn new projects. I had to move directories around. I had to figure out new ways of doing things, all without stopping the developers from doing massive amounts of development.

这是地狱的最内层.

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

One of the reasons why your Ant projects are so complex probably has to do with dependency management. If you are like our current shop, some developer decided to develop their own system of dependency management. After seeing this dependency management system, I now know two things developers should never write: Their own build files, and dependency management systems.

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

Fortunately, there is an already existing dependency management system for Ant called Ivy. The nice thing about Ivy is that it works with the current Maven architecture. You can use your site's centralized Maven repository, and Ivy can deploy jars to that repository as Maven artifacts.

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

I created an Ivy project that automatically setup everything for the developers. It contained the necessary setup and configuration, and a few macros that could replace a few standard Ant tasks. I used svn:externals to attach this Ivy project to the main project.

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

Adding the project into the current build system wasn't too difficult:

• 我不得不在 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 中添加或更改十几行代码才能做到这一点.

• I had to add in a few lines in the build.xml to integrate our ivy.dir project into the current project.
• I had to define an ivy.xml file for that project.
• I changed any instance of <jar and </jar> to <jar.macro and </jar.macro>. This macro did everything the standard <jar/> task did, but it also embedded the pom.xml in the jar just like Maven builds do. (Ivy has a task for converting the ivy.xml file into a pom.xml).
• I Ripped out all the old dependency management crap that the other developer added. This could reduce a build.xml file by a hundred lines. I also ripped out all the stuff that did checkouts and commits, or ftp'd or scp'd stuff over. All of this stuff was for their Jenkins build system, but Jenkins can handle this without any help from the build files, thank you.
• Add a few lines to integrate Ivy. The easiest way was to delete the jars in the lib directory, and then just download them via ivy.xml. All together, it might take a dozen lines of code to be added or changed in the build.xml to do this.

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

I got to the point where I could integrate Ivy into a project in a few hours -- if the build process itself wasn't too messed up. If I had to rewrite the build.xml from scratch, it might take me a two or three days.

使用 Ivy 清理了我们的 Ant 构建过程，并为我们提供了许多在 Maven 中具有的优势，而无需进行完整的重组.

Using Ivy cleaned up our Ant build process and allowed us many of the advantages we would have in Maven without having to take a complete restructuring.

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

By the way, the most helpful tool for this process is Beyond Compare. This allowed me to quickly verify that the new build process was compatible with the old.

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

The funny thing is that once you have integrated your Ant projects with Ivy, turning them into Maven projects isn't that difficult:

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

• Clean up the logic in your build.xml. You might have to rewrite it from scratch, but without most of the dependency management garbage, it's not all that difficult.
• Once the build.xml is cleaned up, start moving directories around until they match Maven's structure.
• Change source to match the new directory structure. You may have a WAR that contains *css files in a non-standard location, and the code is hardwired to expect these files in that directory. You may have to change your Java code to match the new directory structure.
• Break up Ant projects that build multiple projects into separate Ant projects that each builds a single artifact.
• Add a pom.xml and delete the build.xml.

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

Yes, I know this isn't entirely true. There are Maven projects with sub-projects and super poms. But, you will never have a Maven project that builds four different unrelated jars while this is quite common in Ant.

这篇关于将复杂的项目从 Ant 迁移到 Maven - 如何处理异常的文件夹结构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！