<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

Before we get to the why, let’s start with the what. In this case the what is, “what is Gradle.” In the simplest terms Gradle is a Groovy based build automation tool that sits in the middle ground between Ant and Maven. I know there are dogmatic users of Ant or Maven having a meltdown right now. This was not my intent. The statement is meant merely as a very high level generalization of what Gradle is.
So now we get the real question, “Why Gradle?” That’s a fairly ambiguous. Depending on context, it can mean a great many things. In the context of this blog it refers to why I have chosen Gradle. It is not meant to be a comprehensive exploration of Gradle. There are many sites and articles that go into much greater depth than I will in this short post.
On to the meat…
Let’s say you have a legacy (older than ten years) system that has a very “unique” project structure. This structure has no resemblance to more modern accepted project topologies. Building the project requires the invocation of a host of scripts, many pure Linux shell scripts. These scripts are invoked by a custom build tool that remembers Ant when it was in diapers. At this point the build process has taken on a mystical quality with no one quite sure how all the parts work together nor what all the dependencies are. And the properties files required for the scripts are more bloated than a Hutt with a thyroid problem.
Then one day a very wise developer finally manages to get full buy-in for a modern tool to control the build process…Jenkins in this case.
Jenkins is fully capable of running the existing shell scripts for the current build. But now that Jenkins is in place, does it really make sense to just rely on the shell scripts. Or should the momentum be directed towards replacing the scripts?
So moving forward, whispers of Maven arise. Additionally, further analysis of the scripts reveals the presence of Ant scripts buried in the web of the existing build process.
With the support for Maven found in Jenkins, this seems to be the logical direction to proceed. It would help in making the build more standardized and, as a bonus, help with dependency issues that crop up from time to time. In researching the viability for Maven, however, an important complication becomes more problematic. Maven has a tendency to want your projects to follow a very specific pattern. Unfortunately the existing project structure isn’t even close to what Maven needs.
So why not just change the whole project structure? Well, as so often happens with large legacy systems this is not practical in the short-term. Given enough time, resources, and safety blankets for business stakeholders this could be done. But there is more of a chance of someone just deciding the whole migration should be scrapped.
At this point the project is using Jenkins, shell scripts and Ant. What to do, what to do?
Enter Gradle. Can Gradle invoke Ant scripts? Check (though to be honest, so could Maven). Can Gradle invoke shell scripts? Check (once again, something Maven could do as well). Can Jenkins invoke Gradle? Check. Is it easier to use the existing project structure without major structural changes? Check (Advantage Gradle). Would we still have access to Maven style dependency resolution? Check (Gradle has rich support for connecting to Maven and Ivy repositories). Is working with Groovy, which Gradle is based on, more fun than editing XML files? Double-Check (Sorry Maven).
This checklist, along with additional research into the differences between Gradle and Maven, is why Gradle was chosen. Is Gradle always a preferable choice to Maven? Definitely not. When dealing with legacy applications, however, it provides a powerful tool for modernizing the project incrementally.

See More From These Topics