Monthly Archives: February 2017

Gradle UP-TO-DATE Check and exception handling

Published / by msaladin / Leave a Comment

I really feel the time I am quite old sometimes. I am now programming for about 22 years, and exception handling was always an important part of development. This seems to be no longer true.

Gradle is a great build system, it is really nice and you can script your build logic using Groovy, which is better than using XML (ANT) or using only convention (Maven). I am working with Gradle now for about 6 month, and I really like some of the concepts… but exception handling is really hard.

For example, Gradle has the concept that there is some logic which just knows whether a build task needs to be executed or not. For example, if you have a task which compiles Java, and you know all the input files, and the output files, you can compare the input/output from the last build, and the current build, and when the input/outputs did not change, then you don’t have to do the compilation again. This is quite a good idea, so normally, when you build a Gradle project you experience a lot of tasks which just say:

taskname - UP-TO-DATE

This means that the task is not really executed. Gradle has some logic to know all the inputs and outputs of the tasks, so it can compare them, and if they are the same, just ignore the task for this run and don’t execute it. This is really fine as long as it works.

I had a task which copied some JS files into a directory, it too the JS files from a node_modules folder where it downloaded the files first, and then copied them to a generated folder. This would mean that when I delete the destination folder, then the task must really be executed again, because otherwise the file is not copied. When the file is not copied, it is not part of the delivery, and we remark this only when we have successfully deployed the artifact to a system that something is wrong (runtime exception).

The problem was that Gradle always thought that the task was up-to-date… OK, clearly, there was some error in this. With gradle, you can use command-line-parameters to get more information, like -i for info and -d for debug. I tried this to find out why Gradle thinks that my Copy-task is up-to-date, but the debugging output gave me no real value. There was no hint why the task was up-to-date in the debugging output.

To make this one short: The Gradle guys had a really good idea that tasks should not be executed when the input/output match. This works great. But we as developers make errors, and when we make errors, we want that a tool provides us with a meaningful message, at least in the debugging output.

What really was the problem in my case was that I defined the tasks outputs wrongly, so the directory for the output did not exist in the previous run, and as it does not exist now, the current run does not see any difference and just says UP-TO-DATE.

My whole debugging session, the time I lost with it, could really have been decreased by providing a meaningful debugging-output… I will try to contribute my logging to the gradle GitHub project, hopefully they will include it and this will safe some time for other devs.