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 recently had a request from a customer for some guidance on how to automate Staging in Nexus Professional from Gradle. Here was his core problem: he had a series of builds that needed to deploy to a staging URL and he was wondering if it was possible to automate the closing of a repository from Gradle. It is. While we’ve made it easy to do this in Maven with the Nexus Maven Plugin we didn’t have the equivalent example in Groovy. This post gives some guidance to anyone who needs to call out to our REST services from Groovy.