A deep seeded desire to test out Gradle, and to write a blog post littered with pop references, has been brewing for a long time. I recall having a spirited conversation with a fellow Java developer from 10gen during the speakers’ dinner in Javazone ‘13 regarding the pains and tribulations of migrating from Ant to Gradle. Talks awash with Gradle enthusiasms and pleasantries, dredging through fire and brimstone maintaining Ant build scripts, and the verbose perversion that is Maven. This was exactly a year ago.
At the time, our build scaffolding that was prevalent throughout the modules and projects was Ant, backed by a home-baked top level paraent XML files that contains a bunch of common library definitions and tasks. We had things like build-commons.xml, junit.xml and findbugs.xml etc floating around all over shop. Yes, even built artifacts were checked into the repo (not until Ivy was adopted). Like a kid who got caught stealing candy, this was some shameful stuff, but unabashed at the same time, it got the job done. XML for build scripts is like sculpting a statuette with a chainsaw whilst listening to Fallout Boys; a sad emo affair it was.
Readable code == better maintenance
Maintenance was the big factor to consider. Ant build script was growing large, encapsulating everything from executing various levels of testing, static code analysis, docs generation and bundling of certain jars etc etc. The list just seems to go on and on. Changes often break the build scripts and a lot of things are still hardcoded, despite having this build-common.xml on a parent level. Trying to explain the build process to someone was also extremely difficult. The silver lining here is that it is still not nearly as bad as the notorious Netbeans generated Ant build scaffolding.
Gradle simplifies the tasks, without the verbosity and rigidness of Maven. The flow of the build process for Gradle is govern usually by the plugins and it is super easy to extend and customise. Since we are all developers at heart here, reading lines of code instead of hundreds of lines of XMLs is a lot easier to swallow.
DSL > XML
Groovy is, well, groovy! Pardon the pun, but nothing is more clever than being able to spout random functional programming anecdotes in a company surrounded by C programming dinosaurs. One does sound a bit more hoity toity when using words like curring, closure, map reduce, and having debates on whether curring is monadic. I mean pointers and kernels just don’t cut the mustard in hipster convo these days.
Getting out of dependency hell
The highway out of dependency hell is Gradle. The reason being is the built-in dependencies and insight command. After working on NPM and Bower for over a year, being able to specify the type of dependencies (compile, runtime, dev etc) is paramount to getting on top of the dependencies dump in the first place. Previously with Ant, multiple classpaths had to be defined carefully, all of which ends up messing up our IDE.
You will also be well equipped to sort stuff out when logback, slf4j and log4j decides to not play nice together. Oh yes some obscure version of the three, when combined, will throw class loading exceptions. It is like an unholy trinity, and believe me, you want the Gradle gods on your side then to find the culprit.
In the end…
Happy to say that after a year of wallowing in despair and ignominy, the build scripts and build pipeline has gotten some major love and finally migrated to Gradle. A happy hipster day indeed.
Thnks fr th mmrs Ant! Now go pop some tags, you got Gradle in your pocket, hunting and looking for a come up, you know everything with Gradle is fucking awesome.