Gradle Review

Gradle

Gradle is a build tool, I personally use it to build some old java projects but it can do other things.

I've given it a chance now so feel I can blog about it.

I like, no I love the idea of Gradle, however the implementation isn't good enough :(

It's not that it lacks features, quite the opposite there are so many that the basic set have been neglected in favour of the more fun stuff.

Essentially there needs to be another layer to add simplicity, you need to know too much about the internal workings of the system for it to be all that useful to build systems that already exist.

It probably works well on basic systems, and if starting a new system you can adhere to all the rules it'd probably rock, but for making existing builds better it becomes an uphill struggle where the benefits are sadly overshadowed by the difficulties in getting there.

If there was more IDE support then it would probably be far easier and I would be writing a totally different blog but until it is my opinion stands.

Specifics on whats wrong

I have a legacy system that I am trying to move away from using Ant, as is always the case the build has become incredibly over-complex which means an incredibly verbose xml build file and many workarounds for the immutable nature of ant.

I like the idea of being able to use actual proper code in the build when some conditional stuff is required, ant wholey fails on this count by forcing you to make custom tasks e.t.c. for very obscure conditions rather than allowing quick in line code.

I create a set of jar files from a particular project, I am using the 'java' plugin which gives me some handy stuff, but goes too far!!  It gives me a default jar of all of my code which I don't want and using what seems obvious to switch it off 'jar.enabled =false' seems to have no affect.  The suggested alternative was
configurations.runtime.with{
  artifacts.remove artifacts.find { it.archiveTask.is jar }
}
YUK! this is forcing me to know about the internal workings of the thing I want to use, which is wrong.  I don't want to spend ages learning about a damn build tool I just want my source to go in one end of a black box and have my compiled jars pop out the other end.  I mean I use my car and tv to perform the tasks I want adequately yet I don't need to know what's going on inside in order to do so.  To me this is where the design of the api starts to fall down.

I used another plugin 'ear' which helpfully created a packaged ear file, I needed an exploded one but there seems to be no simple way to stop the ear being zipped up, yes I could add a doLast() to unzip the ear but come on seriously why would I waste time zipping to begin with!

UP-TO-DATE
The idea of an up to date check sounded like the best thing ever, you have a task tell it what the inputs will be, what the outputs will be and when there has been a change the task is run, yet if the system hasn't changed the task isn't run thus saving tons of unneeded build work.


Yes it does sound like a good idea but it simply doesn't work.  I currently have a jar that is part of an ivy repository that is downloaded and unzipped.  Therefore the task to do this has the zip as an input and the output dir as an output.  This task never runs as it is ALWAYS up-to-date, I've created the output dir and put stuff in it, I've altered the source zip, I've even added an upToDateWhen closure and this is never triggered Gradle simply responds that the task is up-to-date.

More overengineering

Another thing that simply wound me up about Gradle but I was prepared to deal with on the assumption that the rest of the sales rhetoric was at least vaguely truthful was the dependency mechanism.  There are already tried and tested dependency mechanisms, my project used to use Ivy so why can't Gradle just use Ivy?  As far as I have discovered there is No benefit of gradle dependecy management over ivy!

Conclusion

I really like the idea of Gradle and when I went through the typical hello, world tutorials it all seemed nice.  It's only when you want to deviate from the path of what the originator of Gradle deemed to be the route to take that you realise just how hard it is to use.

There is a lot of documentation, there is a host of helpful people (and unhelpful) that are willing to offer assistance.  This is all brilliant and I commend those that are involved with it.  This article does sound like a bit of a downer on Gradle which I don't want it to be because I believe it'll be fantastic one day, however it isn't yet and it would appear that more features are being added rather than sorting out the current failings which could end up turning Gradle into unmanageable bloatware like so many tools (maven) that have come before it.

For me the ideal build tool would be nothing like what has gone before, no fancy convention over configuration none of that just a set of libraries for dealing with typical build-like tasks (file copying, dependency resolution, compilation...) and let whomever needs the build use it however they want rather than attempt to steer them in what I believe to be the right direction because with legacy there is no standard way these things have been done and the time to convert them cannot be justified, it's just a build tool!