Changing Gradle Wrapper versions

When using Gradle, it’s recommended to use the Gradle Wrapper. The wrapper allows you to easily distribute your projects to people who don’t have Gradle installed, and it makes sure your build is repeatable by not breaking when new versions of Gradle are released.

To create a wrapper file, executing gradle wrapper is enough.

Upgrade/downgrade wrapper versions

If you want to up or downgrade the Gradle wrapper, you can execute the command gradle wrapper --gradle-version X.Y. This is a feature introduced since Gradle 2.4 and allows you to easily change the wrapper version.

Getting started with Asciidoctor

One of the best ways to get started with AsciiDoc is to use the Asciidoctor toolchain, and specifically the Gradle integration. Ironically, the documentation on how to do this is not always clear, so this blog is an attempt to make things a bit easier.

To get started with AsciiDoc and Gradle, we’ll create a new Gradle project, add the AsciiDoc support, and then create a small demo page to get you started. So, open a Terminal, and type the following commands:

The above will create a new empty Gradle project. Now, open the build.gradle to add the required configuration for AsciiDoc.

The last thing we’ll have to do now is to create an intial document, and you’re ready to go. The default source document used by AsciiDoc is src/docs/asciidoc, so let’s create that directory:

Then, create a file in that directory. The extensions .ad, .asciidoc and .adoc are supported, where .adoc is the most widely used. I choose the file ‘test.adoc’:

If you now run the AsciiDoc Gradle task, by executing the wrapper script: ./gradlew asciidoc, then a beautiful AsciiDoc HTML file called test.html should end up in build/asciidoc/html5.

Getting started with AsciiDoctor

Groovy in Action Second Edition PDF and Paper

Only 4 days ago, the paper version (pBook) of Groovy in Action was released, and with the release of the electronic edition (PDF, epub and mobi), all the editions of Groovy in Action, Second Edition, are fully available! So, what’s exactly covered in the book?

The book is divided into three parts. The first part of the book is about the Groovy language. The second part is about working with the Groovy library, while the third part dives into applied Groovy, showing you some best practices around tests and some other frameworks closely related to Groovy.

In the first chapters, the Groovy Basics are covered. The Groovy basics, as the name implies, covers the foundation of Groovy and gives a great start to grasp the language. This chapter is followed by the Groovy Datatypes and Collections, which really show the power and flexibility of Groovy, and showing the start of learning how to use functional programming with the Groovy programming language. This is completed by introducing Closures, one of the core language elements of Groovy. The chapters after this make the first part actually already a complete book, and we could have stopped there if we wanted to limit ourselves to the language only. But the reasons which make Groovy such a compelling choice is not only the flexibility of the language, but also the ecosystem around it.

So, in the second part of the book, the Groovy library, covers technologies like the working with the GDK (the methods added to the JDK by Groovy), Database programming (covering SQL as well as NoSQL databases), XML, JSON, Webservices, and a full chapter packed with tips on how to integrate Groovy into your current software pipeline.

To finish off, the 3rd part of the books (and we’re already 600 pages into the book by now) covers the focus of my work for the last 10 years, which is software testing. A lot of that knowledge has been put into the Groovy book, and I really hope it will prove useful in increasing the quality of your software. Besides testing software, concurrency, always a complex topic, and DSLs, which for me, is one of the most interesting chapters in the book, since it brings a lot the previously covered chapters together and shows some real world examples on how to build your own DSL.

I’d like to thank my co-authors from who I learned a lot about writing Groovy in Action, as well as the Groovy languagehor! We really hope you’ll enjoy reading the book as much we had fun writing it, and if you have feedback, comments or compliments, let us know, we love to hear from you!

Gradle: renaming build.gradle to moduleName.gradle

When working with multimodule projects, having many build.gradle files with the same name can be confusing. Gradle provides a way to change this behaviour by using the settings.gradle file, which you can put in your project.

An example settings.gradle file is listed below.

As you can see here, the buildFileName of the main project is now called epub-organizer.gradle instead of build.gradle. For the sub projects (ie the children), the project name is retrieved, replacing all upper case characters with the lower case equivalent, prefixed by a dash, so that epubOrganizer will become epub-organizer. Of course, this is just an example, you can use any naming convention you’d like!

Gradle: creating executable jars for DropWizard

Some days ago, I created a Simple REST interface for my Open Source Epub organizer. I used the excellent DropWizard documentation, which guides you through the process. However, the DropWizard documentation uses Maven. While that’s not really a problem, I’m trying to switch to Gradle.

For creating a executable jar in Gradle, there are some plugins available, like the FatJar, UberJar. It’s also explained in a sample DropWizard project. However, if you look at the forks, all the forks are different. Some of them use FatJar, some use UberJar, some switched from one to the other, etc. It’s a bit of a mess. Fortunately, there’s also support from Gradle itself, and while the documentation is a bit minimal in this area, it works very nicely.

Running a ./gradlew jar will create an artifact in the build/libs directory. You can then run java -jar build/libs/epub-organizer-dropwizard-1.0.jar, et voila, the executable DropWizard jar is working:


usage: java -jar epub-organizer-dropwizard-1.0.jar
[-h] [-v] {server} ...

positional arguments:
{server} available commands

optional arguments:
-h, --help show this help message and exit
-v, --version show the service version and exit

If you want to test the DropWizard application without building a jar, that’s also possible. For that, you can use the Gradle application plugin, in the following way:

You need to define the mainClass and optionally a run block, which will pass the arguments to the main application. Running ./gradlew run will then run the DropWizard application:

GET /hello-world (nl.jworks.epub.dropwizard.resources.HelloWorldResource)

INFO [2013-07-16 18:33:15,863] com.yammer.dropwizard.config.Environment: tasks =

POST /tasks/gc (com.yammer.dropwizard.tasks.GarbageCollectionTask)

INFO [2013-07-16 18:33:16,457] org.eclipse.jetty.server.AbstractConnector: Started InstrumentedBlockingChannelConnector@0.0.0.0:8080
INFO [2013-07-16 18:33:16,463] org.eclipse.jetty.server.AbstractConnector: Started SocketConnector@0.0.0.0:8081

In short, no need for extra plugins, but using the Gradle core functionality most of your requirements to create executable jars should be covered.

Jacoco code coverage with Gradle

One of the new features of Gradle 1.6, the Groovy based build tool, is Jacoco support. Jacoco is one of the few (only?) Open Source code coverage tools still in active development, and starting from Gradle 1.6, it’s now a supported plugin. Enabling the task is easy, just add

to your build.gradle, and run ./gradlew jacocoTestReport and it.. does nothing. For those running into the same issues, this might save you a bit of time:

After a bit of searching, it turns out the Jacoco plugin is a bit broken. When using it with a Java project, as I’m doing, you need to do a couple of things to enable it, but also then, it unfortunately doesn’t work as advertised, though the fix seems not to complex.

First, you need to enable the following:

And then, instead of running ./gradlew jacocoTestReport as mentioned in the docs here, you need to run ./gradlew test jacocoTestReport. Unfortunately, no location is printed where the documentation is created, so no clickable links in your terminal, but you can find it under build/reports/jacoco/test/html/index.html. Well, that wasn’t so bad now, was it? Have fun!

More resources

For more information about using Jacoco and Gradle, you can checkout the following resources:

Creating projects with Gradle

Coming from a Maven background (Maven 1, 2, 3), I find it a bit strange that Gradle doesn’t provide archetypes like Maven does. There’s a template plugin, which helps a little, but besides that, you’re out of luck. Or are you?

I found a pretty neat Gradle script in their Jira system, which can create a directory structure for you even when working on a Groovy or Scala project. The easiest way to do so is to add the following ‘initProject’ task to the Gradle build.gradle:

You can call it by executing the following command:

This works great until Hans or Luke decide to create the

command, which would make our lives even easier!