We’ve now reached the time of year when I need to think about initiating the Groovy & Grails eXchange call for papers, so I thought I’d take this opportunity to both resurrect the talk submissions app I created a while back and try to upgrade it to Grails 3. Up until now, I hadn’t properly used Grails 3 for anything, so it seemed like a good opportunity to learn how it differs from previous versions.
Here’s what happened next…
Gradle fans have been discussing a recent article on Gradle and the halting problem. The premise is that a program (such as an IDE) can not reason about a Gradle build without first executing the build script. And since the build script is written in a Turing-complete language (Groovy), it may never complete execution and you won’t even be able to discover a build’s dependencies.
Back in my youth, programs used to come as listings in magazines that you copied into the ZX81’s BASIC editor and then ran. How times have changed. Building software has become more complex as the underlying runtimes and platforms have evolved. As a result of that, we have seen an evolution in build tools. I started my working life using Make (for both C++ and Java), before progressing onto Apache Ant and Apache Maven 2. For a brief interlude I even worked with CMake, which I found to be one of the more challenging tools to learn and understand.
Gradle is a recent entrant to the field, and my current build tool of choice. What lifts it above the more established tools, Ant and Maven? This is a question that anyone involved in building Java software in particular should be asking themselves.