In the early days of Java development, we either didn’t see much of a need for build tools, or used what we had from other environments. I can still remember building shell scripts and make files for developing Java. The make files were especially interesting, because this was a tool that just wasn’t designed with Java in mind. It was also difficult to move to different operating system environments.
Where I was working back in those days, we developed on Solaris, but we had some projects that existed on both Windows and Solaris – which was one of the reasons we found and began using the ‘new’ language, at least new back then. This made the shell scripts impossible to use, and the make files difficult at best.
When Ant came out, we jumped at it. Like the language we were working in, it was cross-platform. That was a huge benefit to us.
I remember when Maven came up, there was some resistance, because we had Ant. But by this time, some projects had become large enough, and complicated enough, that it was painful to write and maintain the Ant files. With the advent of war files and loading dependency jars from the classpath, it was also becoming distracting to find, download, and install all the dependency jars for each project. Maven’s promise of dependency management and the simplification of build by convention made this tool a must-have on several projects. Many of the shops I’ve worked in over the years have embraced the features that Maven brings to the programming environment.
So the question becomes: with such a powerful tool, do we need any others?
As an illustration, I’ll go back to the days before I became a programmer and worked construction. Since I was the son of the company owner, I “got” to work in all areas of the construction process. I found I really liked the framing hammer. It had a good heft to it and I could drive 16 penny nails pretty easily with it. So I used it everywhere; I used it framing, putting up sheetrock, finish work, roofing, but not so much for electrical work.
If I had used a lighter hammer, I’m pretty sure there would be a few houses in south Mississippi that would have just a little less spackle on the walls where that framing hammer drove the nail a tad too deep (this was before sheetrock crews used screws to hold up sheetrock). I also saw how much benefit the roofing crews got from using a roofing hammer. I probably would have busted my fingers a lot less if I had used one. Moral: Even if every problem looks like a nail, not all hammers are the right solution for the job.
About Gradle
I’ve recently been looking at the Gradle build tool. The one thing that stands out to me right off the bat is that the build file is not XML, a properties file, or any other configuration-only text file. It’s a Groovy script. From the first part of this article, I think you can tell I’ve been a Java programmer for quite some time. Before that, it was C and C++. C-based languages, especially Java, are second nature to me. XML is something my code outputs or is used to provide configuration for a server or other tool. I don’t work with the structure of it nearly as much as I work in Java, which is all day. I feel right at home with Groovy, as it is based on Java.
This article is not intended to be about switching from Maven to Gradle, but about why Gradle should be in your tool belt. Steve Ebersole has a great article about why Hibernate has moved from Maven to Gradle for their development builds. In my opinion, Maven is still a great tool when you have a project that can, or should, use the Maven conventions.
This is also not meant to be a tutorial on how to use Gradle. There are some good places to start already available, including the user guide on the Gradle website.
Gradle provides very good integration with IDEs. Netbeans’ newest version especially seems to work well with Gradle. Gradle has a much better multi-module build system, its plug-in system is powerful and straightforward, as is writing plugins. In my opinion, it is a very well-written and mature build tool.
An example in action
The most powerful feature to me for Gradle is the fact that the scripts are code. Groovy to be exact. Occasionally we all run into projects that have one requirement that sets them apart from other projects. A couple of times I’ve written quick Griffon projects to maintain configuration data that I would otherwise have to maintain SQL scripts for. Griffon is a Groovy rapid desktop application environment to produces standalone applications that can be deployed as runnable JAR files or applets. When I would have to make changes, I would then have to copy it to a directory that I ran the application from, or to the network for someone else to run it.
Gradle allows me to write that logic build script. Since Gradle is based on Groovy, it comes with all of Groovy’s, and Java’s, tools and libraries. As an example, adding a Swing dialog to choose what directory to copy the JAR to, and then doing the copy is as simple as adding the code to the build file:
import javax.swing.JFileChooser
def dirDialog = new JFileChooser(
dialogTitle: "Choose directory to copy jar to",
fileSelectionMode: JFileChooser.DIRECTORIES_ONLY,
approveButtonText: "Set directory",
acceptAllFileFilterUsed: false
)
task copyJar(type: Copy) {
from 'build/libs/DocExample.jar'
def targetDir = dirDialog.showSaveDialog()
if(targetDir == JFileChooser.APPROVE_OPTION ) {
targetDir = dirDialog.getSelectedFile()
into targetDir
}
}Then run the copyJar from your IDE or command line, task to select the directory, and copy the file.
Okay, that might be a little contrived, but consider a similar requirement to FTP a file to or from a server during build. You could use something like SimpleFTP from Jibble to provide that requirement. Since this ships as a JAR file you can place on your class path, you can simple use it in your build script the same way I use JFileChooser here.
In conclusion, Gradle is a powerful and versatile tool that deserves a place in your tool belt.
