Gradle: do we need another build tool?

by on September 9, 2013 10:05 am

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.

— Rik Scarborough,

  • Share:

2 Responses to “Gradle: do we need another build tool?”

  1. Rex Sheridan says:

    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.

    • 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.

Leave a Reply

Things Twitter is Talking About
  • We're excited for Tech Night tonight! @LyndseyPadget is presenting to the team "REST For an Hour" in preparation for her @NebraskaCC talk.
    March 5, 2015 at 3:40 PM
  • DYK? We prefer diverse views, so the info we share doesn't always reflect us as a company. See our Social Policies -
    March 5, 2015 at 3:20 PM
  • Every member of an #Agile team affects its overall success. See what not to do - Agile Team Member Anti-Patterns
    March 5, 2015 at 1:35 PM
  • #TBT Our past blog series on what makes a great #Agile Retrospective - As important today as when it was written!
    March 5, 2015 at 10:35 AM
  • Sought to find a precise JSON querying API for #Backbone like what I knew with #Java & PL/SQL. Meet backbone_query -
    March 5, 2015 at 9:35 AM
  • Every member of an #Agile team affects its overall success. See what not to do - Agile Team Member Anti-Patterns
    March 4, 2015 at 3:21 PM
  • .@NebraskaCC is just 2 weeks away & tickets are still available! #KC developers: Lincoln is just a quick 3-hour drive away. Well worth it!
    March 3, 2015 at 10:59 AM
  • Happy Punday from the Keyhole team! :-) We hope you're having a great day.
    March 2, 2015 at 2:54 PM
  • There's a new post on the Keyhole dev blog from @joshuarob01 - Agile Team Member Anti-Patterns #agile
    March 2, 2015 at 10:57 AM
  • Heard of #GrokOla yet? Q&A with our expert dev team + code-sensitive wiki for tribal knowledge
    February 27, 2015 at 1:38 PM
  • Rapid appdev has a bad rep, but there are ways to bring development time down the right way. Don't Fear the Rapid -
    February 27, 2015 at 1:05 PM
  • RT @DZoneLinks: Swift 1.2 Arrives: 13 New Features - - @DZoneLinks Big Link by mswatcher
    February 26, 2015 at 2:17 PM
  • Our GrokStars are at it again - they've released a free #GrokOla primer. Get to know Java Lambdas:
    February 26, 2015 at 9:13 AM
  • RT @dbgrandi: OH: “Do programmers have any specific superstitions?” “Yeah, but we call them best practices.”
    February 25, 2015 at 6:05 PM
  • New Primer: Introduction to the #Backbonejs MVC Framework - Free #GrokOla tutorial available to the public.
    February 25, 2015 at 4:26 PM
  • #RabbitMQ: messaging software built on AMQP protocol. Learn relevant concepts & how to avoid common "gotchas" here:
    February 25, 2015 at 3:20 PM
  • #Java is OO but contains non-object primitives. Autoboxing feels more like a band-aid. Do primitives need to go?
    February 25, 2015 at 1:44 PM
  • We're excited for Tech Night tonight! @bricemciver will present to the team on Leaflet.js in preparation for his @nebraskacc talk. Lucky us!
    February 24, 2015 at 4:15 PM
  • Do Primitives need to go in enterprise apps? - New #Java post on the Keyhole blog.
    February 24, 2015 at 3:31 PM
  • When you pair #JAXB & #JPA, you can expect some "gotchas." Here are techniques to help you overcome the hurdles -
    February 24, 2015 at 8:15 AM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2015 Keyhole Software, LLC. All rights reserved.