Gradle: do we need another build tool?

Rik Scarborough Java, Technology Snapshot 2 Comments

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.

See Also:  AWS Lambda With NestJS

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.

See Also:  Spring Boot and React: Happily Ever After

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.

— Rik Scarborough, [email protected]

Comments 2

  1. I honestly think the example you have chosen is exactly the reason I would never want to use Gradle. Every Gradle script I have seen looks different from the last. This increases the maintenance burden since you have to learn the differences for each project you encounter. I claim Gradle is not evolution but de-evolution. Sure XML ain’t fun but with convention comes sanity. I love my job but my job isn’t to just write more code; it’s to solve problems. When it comes to writing rock-solid systems that survive a long time the boring solution is usually much better than the interesting one.

    1. Rex, thank you for your comment. You make a very valid point in that standardization across projects is very important to maintenance. In my opinion, that can better be obtained through standards rather than restricting the tool set. We should be able to trust our developers to maintain that standard.

      The same example I show here can be achieved using Maven and Ant with plugins. I have seen many different versions of Maven build files, especially when we throw in different plugins. Ant can be even worse. A future version of Maven will even have scripting capability. I fail to see how that helps the maintenance burden, unless you make a standard that all the developers are going to use. In my opinion, and a point I tried to make here is, I believe when you have to achieve a solution to a problem different than the norm in an XML-based build tool, it actually adds to the maintenance burden. I have to understand what the build is doing in XML, which is not a “native” language for me. While I, and most Java/C programmers, understand it well, it’s not as readily intuitive as Groovy is.

      And I failed to point out that Gradle uses convention as part of its build process. Like in Maven, I can write a very basic build script that will accomplish the build tasks for a majority of projects. This script can be standardized across an entire enterprise, just as Maven pom files and Ant build files should be. This article was meant to point out that in those cases where the problem we have to solve is not in the majority, Gradle is easier to extend than attempting to “code” in XML or create another project to develop a plugin taking precious time away from the original problem we are trying to solve.

      While I agree that adding a technology just because it is interesting is foolish, unless the project is a personal one meant for self-improvement, rejecting a technology because a programmer might abuse it would prevent us from ever increasing our productivity. We would be locked into systems that may or may not solve the problems we are facing.

      If Gradle does not solve any problem you have, then by all means do not use it. But to reject it from your toolkit completely might restrict you from a better solution at some point. A timely, effective, and maintainable solution should always be our goal.

What Do You Think?