Whenever I teach a Maven training class someone invariably asks me to give some advice for migrating a large, complex Ant project to Maven. Toward the end of the class, I’ll take questions:
Participant: “Could you give us some guidance for migrating Ant projects to Maven? Is there a process that you recommend to make it easier.”
My (honest) answer: “If it’s a complex project, it won’t be an easy battle. Before you go down this road you need to understand what you are signing up for. It can be very complex, you may end up interrupting an active development cycle, and once you evaluate all of your options you might find it easier to first migrate to a repository manager. Maven’s not the big win, moving a repository is.”
In other words, I often find myself trying to discourage swapping build tools just for the sake of swapping build tools. While I do believe that Maven is preferable to Ant, I think that the build space often suffers from a belief that the grass really is greener on the other side. It might be, but is it greener enough to justify that work stoppage that is involved in taking a big important project and moving it to a different build technology? Often the answer is no. If it isn’t related to making money, switching a build system is often the last thing an enterprise wants to do.
In this post I’m going to talk about the process of migrating build tools starts with a repository manager.
I’ve seen my fair share of projects migrating from Ant to Maven, and, for a complex project, this migration path can take some time. You have to worry about dependency management, project structure, and retraining an existing team to use Maven and understand the core concepts behind the tool. When you make the shift, you are often affecting development infrastructure for an existing project, and you need to take into account development environments as well as developer’s ideas about how code should be organized and stored in source control. In this post, I’m going to discuss a common pattern I’ve seen in Ant to Maven migrations: how to migrate the monolithic project.
In the previous post in this series I discussed three compelling ways in which a repository manager can benefit the development cycle. It proxies artifacts locally, it is optimized to store binary artifacts, and it facilitates a new level of collaboration and agility that isn’t possible when your SCM is only way for workgroups to collaborate. In this post, I’m going to talk about how a repository manager works in concert with a continuous integration server like Hudson or Bamboo.
Sonatype has spent the last few years investing in the Maven ecosystem. We’ve created solid documentation, we’ve invested heavily in making sure that m2eclipse provides solid IDE integration, and we’re about to unleash even more tools that will make it even easier for developers to develop and share software. Here’s an excerpt from Dave Johnson’s entry on converting the Roller project’s build to Maven:
I was a Maven hater and resisted it for a long time but over the years Maven has gotten much better, it’s well supported in IDEs and as far as I can tell, Maven has replaced Ant as the de facto build system for Java projects. If you want new developers be able to easily build, debug and run your code via command or their favorite IDE then Maven is the way to go, and that’s especially true for open source projects like Roller. That’s why I spent a couple of weekends learning Maven and converting Roller’s build process from Ant to Maven (ROL-1849). The process of conversion wasn’t too difficult.
Les Hazlewood has an objective summary of why he eventually came around to deciding that Maven is a better overall solution then Ant + Ivy. This is an evolution in thought process that we, Sonatype, often see in enterprises and Les has two blog entries that illustrate this evolution perfectly.
Maven 2 vs Ant+Ivy: Our selection process: This entry gives Les’ original perspective on Maven and the process by which he originally decided to choose Ant + Ivy.
Maven 2 vs Ant+Ivy: Revisited: This entry gives Les’ new perspective and why his enterprise team, and the Apache Shiro project, have chosen Maven.
I now firmly believe that Maven 2 is a better build and project management tool than Ant+Ivy. I was wrong.
Yep, I said it. I’m man enough to admit when I’ve made mistakes and that I’ve learned from my experiences. And this is coming from the guy that wrote a (still popular) OnJava article for Ant in the enterprise.
Overall, life with Maven is good. I’m glad that I was able to swallow my pride, really give it a chance, and in turn reap the benefits. I haven’t used Ant in over a year since switching, nor have I ever felt the need to go back.
We hope this perspective helps potential enterprises save time when looking for a build and release infrastructure.