Gradle

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, asktheteam@keyholesoftware.com

  • 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
  • Don't miss the newest post from @bricemciver: Make Me a Promise - http://t.co/obK811q48q #JavaScript
    October 20, 2014 at 10:43 AM
  • RT @DZone: #Docker 1.3 Releases with Security, Signed Images, and Process Injection by @bendzone #devops http://t.co/uytIwFPgO6
    October 17, 2014 at 10:04 AM
  • If you have 15+ years #Java exp, you don't expect to be puzzled debugging a null pointer exception. See an exception: http://t.co/m2iDgNEleK
    October 17, 2014 at 9:51 AM
  • Many on our team attended the #Royals victory last night & @cdesalvo even got a selfie with the Gov. Go #KansasCity! http://t.co/N1Psooe2CE
    October 16, 2014 at 3:39 PM
  • Interesting ExplainLikeI'm5 talk: Why do companies develop iOS first when Android holds 70% of the 'Smart' Market? http://t.co/fxgjIBmqBi
    October 16, 2014 at 12:26 PM
  • We're looking for a top-notch #Java developer to join our team. Learn more about our company culture & the role - http://t.co/0fKsFmN0Ql
    October 16, 2014 at 9:08 AM
  • Want to learn to create custom #Java annotations & process them using the Reflection API? @jhackett01's tutorials - http://t.co/mf1F3eIDY3
    October 15, 2014 at 11:43 AM
  • Happy Ada Lovelace Day! It's a celebration of the achievements of women in STEM - if there's a woman in tech that you admire, tell her today
    October 15, 2014 at 9:13 AM
  • .@fpmoles We absolutely agree - thanks for reading!
    October 15, 2014 at 8:13 AM
  • With 15 yrs exp, @bmongar didn't expect surprise when debugging a null pointer exception. Why it puzzled him - http://t.co/m2iDgNEleK #Java
    October 14, 2014 at 11:20 AM
  • #Royals fans with tickets to tonight's canceled game, here's what you need to know - http://t.co/EErHht3zoN
    October 13, 2014 at 4:23 PM
  • RT @UzilitySoftware: Watch as Wayne explains to the boss, Marvin, what an agile board is about. #scrumalliance #scrum http://t.co/5MzB1bNw…
    October 13, 2014 at 12:01 PM
  • Getting started with #MongoDB? (Flexible #NoSQL for Humongous Data) Here's a free cheat sheet from the folks @Dzone - http://t.co/oBMvICzfcL
    October 13, 2014 at 11:10 AM
  • Brad Mongar's newest post is live on the Keyhole blog - #Java and the Sweet Science http://t.co/m2iDgNEleK
    October 13, 2014 at 8:59 AM
  • RT @housecor: If users have share links to your web app like this: "Go to here. Then click here. Then here." You're doing it wrong. #de
    October 10, 2014 at 2:18 PM
  • CSS is 20 years old today! Happy birthday, #CSS - web design would not be the same without you. http://t.co/8tEMoUjorI
    October 10, 2014 at 9:55 AM
  • Expansion update: remodel, electrical & mudding done; painting in process; carpet to go. We can't wait for our bigger team rooms!
    October 10, 2014 at 8:42 AM
  • Want an easy way to get all of our development blog posts sent straight into your email? Try this new IFTTT Recipe: http://t.co/b9RgUqGU4v
    October 9, 2014 at 10:55 AM
  • #JavaScript & #Java handle secure random number generation differently. Here's how they stack up - http://t.co/QENl4kGVIs #cryptography
    October 8, 2014 at 12:27 PM
  • New to #JavaScript prototypal inheritance? Here are some notes to help you along your way - http://t.co/H2YzahmszJ
    October 7, 2014 at 8:57 AM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.