从蚂蚁迁移复杂的项目，Maven的 - 如何处理不同寻常的文件夹结构？ [英] Migrating complex project from Ant to Maven - How to handle unusual folder structures?

问题描述

在我的新项目我面临与已在一个不愉快的，不受控制的方式成长，多年来几个模块复杂的基础设施。

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个不同的，复杂的蚂蚁文件，它们是连接了多次，SOA架构也产生几个动态蚂蚁文件。它花了几天真的了解所有的依赖关系，并最终建立整个项目没有任何错误。

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.

我的计划是或者是整个项目从蚂蚁迁移到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 are 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和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?

感谢您的所有建议。

推荐答案

下面是一个简单而快速的回答Mavenizing一个Ant项目：

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

不这样做！的

DON'T DO IT!

这是不是有些反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.

问题是，蚂蚁可以让开发商做，你必须在Maven中完全重做野性和疯狂的事情。这不仅仅是目录结构多。蚂蚁允许多个版本的文物。 Maven的只允许每个的pom.xml 有一个 ¹ 。如果你的Ant项目产生了半打不同的jar文件 - 那些jar文件包含许多相同的类的？你会向中堂只是罐子创造半打Maven项目，然后对于那些普通的罐子之间的文件的另一个半打。

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 nave 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.

我知道，因为我所做的正是这一点。系统架构的负责人决定，Maven是新的，好一阵蚂蚁一定是坏的，邪恶的。它没有问题，该工作建立并良好的结构。不，蚂蚁一定要去，和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.

这是地狱的最内侧的圆圈。

This was the inner most circle of Hell.

一，为什么你的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 hack together 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.

幸运的是，呼吁蚂蚁已经存在的依赖关系管理系统常春藤。关于常青藤的好处是，它与当前的Maven架构。你可以使用你的网站的集中Maven仓库，和常春藤可以部署罐子到存储库作为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.

我创建了一个常青藤项目，自动设置一切为了发展。它包含了必要的设置和配置，并可能取代一些标准Ant任务的几个宏。我用 SVN：外部这个项目常春藤附加到主项目

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 文件，该项目。


• 我改变的任何实例＆LT; JAR 和＆LT; /瓶＆GT; 到 ＆LT; jar.macro 和＆LT; /jar.macro> 。这个宏做的一切都是标准的＆LT;瓶/＆GT; 任务做了，而且还内嵌了的pom.xml 中罐子一样的Maven构建做。 （艾维有一个转换任务的ivy.xml 文件转换成的pom.xml ）。


• 我撕掉了所有的旧依赖管理垃圾，其他开发者添加的。这可能是由几百行减少的build.xml 文件。我也撕开了这并签出和提交，或ftp'd或scp'd东西在所有的东西。所有这些东西是他们詹金斯生成系统，但詹金斯可以处理这种不从构建文件的任何帮助，谢谢。


• 添加几行整合常春藤。最简单的方法是删除坛子里的lib 目录，然后通过刚的ivy.xml 下载。要添加或在的build.xml 来做到这一点。
改变code都在一起，可能需要十几行

• 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.

我到哪里可以常春藤整合成一个项目在几个小时的点 - 如果构建过程本身是不是太乱了。如果我不得不从头重新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.

使用常春藤清理我们的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.

顺便说一句，这个过程中最有用的工具是超越比较。这让我很快验证新生成过程是与旧的兼容。

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项目，把它们变成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文件的战争，而code是硬期望在该目录中的这些文件。您可能需要修改Java code以匹配新的目录结构。


• 分手了建设多个项目进入每个建立一个独立的神器蚂蚁蚂蚁工程项目。


• 添加的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.

¹ 是的，我知道这是不完全正确。没有与子项目和超级劲歌Maven项目的。但是，你永远不会有一个建立四个不同的罐子无关Maven项目，虽然这是很常见的蚂蚁。

¹ 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.

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