Liverpudlian Screwdriver
It was while studying electro-mechanics in Manchester that my late father came across an unusual (though not very flattering) term to describe a “tool at hand”: a Liverpool screwdriver (also known as “a hammer”). It was obviously the opinion of the average Mancunian at that time that their counterpart Liverpudlians would happily use said hammer in lieu of a more specialised tool, which was either praise of their resourcefulness or a veiled reference to ineptitude. Regardless, we’re all aware of the usefulness of a simple tool from time to time.
So it is with routine software development tasks. I’m speaking not of the grand act of implementation in the langue-du-jour, but rather of the supporting cast: compile/build/make, difference checking, version mergers, resource bundling, dependency verification, deployment, unit testing and so on. For each of these there is an ever-growing set of screwdrivers and when faced with this perplexing degree of choice it is understandable that one would be tempted to reach for one’s favourite hammer. (My preferred hammer – I don’t mind admitting – is that Swiss Army Knife known as Perl, but there are times when digging a trench with a toothpick ceases to be fun.)
Right now I am faced with the problem of choosing a build tool. Speaking only for myself, I’m happy with Ant (and that’s even without adding Ivy to deal with the project dependencies). It gets the jobs done, and divides them in a manner that is akin to how I would envisage doing them manually myself. For those few times when Ant just can’t cut it, I can just tell Ant to enlist a few blades from my Swiss Army Knife.
This time is different, however, because I’m not just choosing a tool for myself, but for a team. A team of teams, in fact. And there will be even more tasks needing more tools. What I want to achieve is a sufficiently rich, yet simple, set of screwdrivers so that the members of the various teams won’t be tempted (too often) to reach for their hammers.
I am also trying to be cognizant of the fact that individual developers will already have optimized their working environment. They will have their preferred IDEs, their preferred debug tools, their preferred package managers and so on. There was a time when this would have been a serious impediment, but predictable arrangement of source assets and interoperability of project types across IDEs is quite normal today, so there’s every chance of establishing a core toolset that spans the lot. The IDEs of particular interest to me are Eclipse, IntelliJ and NetBeans.
In my case, Java is the lead actor in this drama, and first up in the supporting cast are the build tools: Ant, Maven and Gradle. This might be a case of “too hot, too cold and just right”, which would make the decision easy, but it’s more likely going to be “too hot, too big and lumpy” (with apologies to Robert Southey). Ant is essentially an XML-based hierarchy of procedures for resolving dependencies. Each procedure is usually easily expressed and understood in isolation, though when all the build targets are brought together the combination can be daunting. Maven takes daunting XML to a new level. A Maven build relies on conventions (where things are located, how to convert/compile assets etc.) with any deviations then expressed in the XML and often augmented by external plugins that provide additional functionality. Over time, the deviations and plugins can seem to dominate how Maven gets the job done. (These unwritten conventions can be a challenge when trying to understand the build process, compared to Ant where the operations are all explicit.) Gradle borrows concepts from both Ant and Maven, but thankfully has eschewed XML and instead makes use of a DSL based on Groovy. The concise Gradle build scripts are far easier to follow, but being such a new technology, support for Gradle in the IDEs is far less mature in comparison to either Ant or Maven.
Which to choose? What are the right criteria?
This is an ongoing exercise. More later…
Categorised as: Coding, Technology