Build tools are something I am always very interested in. I have written very complex an extensive build tooling in GNU Make that I never want to repeat in my life. I have hacked on SCons, played with Cons, walked a road with Ant, NAnt, MSBuild, Maven ... the list just carries on. When a new build tool comes out I like to play with it and evaluate it.
I believe build scripts should be very readable and easily maintainable. I also believe that build tools should be flexible for when I need it and the ability to construct software in a polyglot / heterogenous way without me having to fight it in very way.
It is for reasons like the above that in this modern age I have come to like Gradle as a build tool. I am also very interested in critisicisms of Gradle. I believe it is important that all opinions should be evaluated, for even if they seem to be wrong at first sight, they might have been formed in a context where they are absolutely correct. I have read a number of Gradle-negative articles the past two years or so. Some of them were just rants, some had good points. but one that really drew my attention of late, is this wiki page on Gradle by Jaroslav Tulach.
This page dicusses what the author considers to be a flawed design in Gradle. It is termed the halting problem and in over-simplified terms can be seen that one could start up a build script, which will never terminate.
I am from an engineering background and in engineering we don't care about perfect, we care about what works.My inititial reaction after reading the Tulach article was "So what?" I am not a computer scientist, I'm an engineer. This halting problem is an interesting dicussion, but how much does this computer scientist meandering really affect my delivery of quality software?
We get taught how to drive on public roads, how to be safe in doing it and to care about he safety of other road users. We don't have to follow those laws and guidelines. Sometimes you have to exceed the speed limit, sometime you have to drive in the wrong lane in order to solve a problem. (As a matter of fact we can drive how we want, but at some stage that behaviour will catch up with us either in the form of an accident, punishment by law or death). Does this mean road transport and road loaws are a bad thing? No, it is about what works for suatainable behaviour and having the flexivility to go outside of the rules when needed.
Since the article did like to compare Maven to Gradle, it should be pointed out that it is very easy to get a Maven build to lock up via a badly crafted plugin (as is the case for Gradle). The only difference is that one that also cause halting in Gradle via a badly written build script. The author seems to argue that that is a good thing in Maven's XML. I would say So What if Groovy contains a while statement? Should I use it a build script? No, probably not, unless I really need to solve a very tricky problem which at the point in time, cannot be solved otherwise. If I search through all the build.gradle scripts on Github & Bitbucket, how many of them would contain a while statement? Probably none.
The author does make a reasonable point about security. It is easier to parse Maven XML to obtain a list of dependencies, that it would be to do from a Gradle script, but once more plugins are addd to Maven those bets are off to as one does not know what can be added through Maven third-party plugins without running the build!
For now though, in my context and the contexts and most other Gradle users, the halting problem does not matter. We know the rules of the road for Gradle. If we stick to the patterns, they will usually do what we need and the Gradle DSL will look like a DSL and not a Groovy script.
I think the one thing that many people are missing is that Maven and Gradle are not really comparable. Gradle falls into a new generation of build tools, a generation beyond that of Maven, Ant or Rake. It is trying to break new ground. There are going to be mistakes made and issues in designs will occur, but without those learning will not happen. Without learning there will be no progress. There will also come a day when there a better build tools that the Leiningen and Gradle generation.
In conclusion, please write more critical (not ranting) articles about Gradle, for then the tool (and other build tools in its generation) can be improved, but please make sure you have your facts right.
