Gradle, etc.

Volume 18, Issue 1; 16 Mar 2015; last modified 06 Apr 2015

A few thoughts on improving build processes.

Anyone can do any amount of work provided it isn't the work he is supposed to be doing at the moment.

Robert Benchley

As a diversion from the pressure of the sprint to ship MarkLogic 8 , I did a fair bit of behind-the-scenes reworking and refactoring of some of my projects. Mostly, I tinkered with the build and engineering release processes. Mostly in aid of making Depify easier and better.

First, continuous integration (CI) servers are a modern marvel. If you build software with any kind of seriousness, you have your code in a source code repository and you have unit tests and test suites and regression tests, and at the end of the day, you're only human.

Your CI server is not. It is ruthlessly, unremorsefully, rigerously pedantic. On every commit to your repository, it will build your code and run your tests. Did you fail to commit a change? CI will find it. Did you install a library locally and forget to add it to the repository? CI will find it. Did you upgrade something in your local environment that's masking a bug, CI will find it.

The Travis CI service for projects hosted at GitHub is simply fantastic.

Above and beyond building code and running tests, CI can be told to do other, useful tasks upon success (or failure). I've now arranged for several projects ( XML Resolver , xslt20-java , annotations , XML Calabash , and the XML Calabash documentation ) to build and deploy distribution artifacts upon the successful build of a tagged commit.

It was a little bit of effort to make the whole thing work, but it's a huge improvement in process. Instead of any fiddling with the release, I make the “I'm doing a release” commit, CI says it worked, I tag that branch, I push the tag, and a release happens.

The other major change in process was the switch to Gradle for project automation. I'm going to be completely honest: I am not a big fan of Groovy , perhaps because I haven't really gotten my head around it, and I find a lot of Gradle damned near impenetrable, perhaps for the same reason. But I managed to get it all to work and I managed to usefully take advantage of Maven repositories. I even, sweet $DIETY , managed to work out how to publish Maven artifacts with Gradle, a task I only sporadically managed to accomplish with Ant .

I think that's better. Writing again is better too. I must try to keep it up.

Comments

You've linked to Wikipedia with a broken link.
Broken:
http://en.wikipedia.org/wiki/Groovy_%28programming_language
Corrected:
http://en.wikipedia.org/wiki/Groovy_%28programming_language%29

—Posted by Derek on 17 Mar 2015 @ 07:53 UTC #

Thinking of Gradle and MarkLogic, take a look at Rob Rudin's ml-gradle project.

—Posted by Dave Cassel on 27 Mar 2015 @ 03:58 UTC #

Thanks, Derek. Fixed.

—Posted by Norman Walsh on 06 Apr 2015 @ 07:04 UTC #