Posts

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

Gradle: displaying artefact locations

Gradle’s output, unlike verbose build tools like Maven, is very terse. In my opinion, a bit too terse. For example, when running gradle jar, this is the output:


:epub-organizer-core:compileJava UP-TO-DATE
:epub-organizer-core:processResources UP-TO-DATE
:epub-organizer-core:classes UP-TO-DATE
:epub-organizer-core:jar UP-TO-DATE
:epub-organizer-dropwizard:compileJava UP-TO-DATE
:epub-organizer-dropwizard:processResources UP-TO-DATE
:epub-organizer-dropwizard:classes UP-TO-DATE
:epub-organizer-dropwizard:jar UP-TO-DATE

BUILD SUCCESSFUL

Total time: 13.752 secs

Okay, that’s nice, looks good, but now what? Where’s my jar? Remembering that it’s produced in build/libs is easy, but a less frequently used task like distZip will produce it’s artefacts in a different location, so you’ll have to remember those locations to. Luckily, Gradle is a very flexible build tool, and with the help of my friend Marcin Erdmann, we came up with the following Gradle script, which you can put in ~/.gradle/init.gradle, or as I did, in my build.gradle file. If you put it in your init.gradle file, please be aware that you’ll have to remove the ‘gradle.’ prefixes.

After each build, the following will now be produced:


:epub-organizer-dropwizard:classes UP-TO-DATE
:epub-organizer-dropwizard:jar UP-TO-DATE

BUILD SUCCESSFUL

Total time: 13.752 secs

Output location: /Users/erikp/User Files/Projects/epub-organizer-gradle/epub-organizer-dropwizard/build/libs/epub-organizer-dropwizard-1.0.jar

Still pretty terse, but quite useful anyway.

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!

This (two) week(s) in Discobot (30-31.2011)

Each week, we work on the Discobot project, which goal it is to make Groovy run on Android. While that in itself isn’t the biggest problem, as you can read in our previous blog posts, making developing for Android using Groovy and making sure we are feature complete, well, let’s say it’s challenging.

Current efforts are twofold: one is developing a set of developer tools using Gradle, on which Marcin is focusing the most. On the other hand, we need some tools to make sure our version of Groovy works on Android, which is what I (Erik) am focusing on.

Screen-shot-2011-08-09-at-9.53.44-PM

As you can see in the screenshot above, our project is already capable of building the project and installing it on the emulator using the Gradle plugin. Also, the start of a demo application has been built, which will allow us to run all the tests packed with Groovy. For that, we have tweaked the build process of Groovy itself, so that it produces a jar which includes all the tests. This jar is used in the Discobot project. To figure out which tests are available, an Android Classpath Scanner is used. It uses a hack by inspecting the Dex files itself, but we are currently using that to scan for files which extend from GroovyTestCase, and run those. Once that is working, we’ll probably write a better UI around it.

Also, the Gradle plugin still needs some finishing touches to improve the overall user experience. Marcin is currently working on the last gradle task which will initialize the android project structure. It will call the android create project command-line tool from Android SDK, change the src directory structure of your project to obey Gradle conventions and create a ‘Hello World’ activity written in Groovy, so you can quickly get a simple working application to start out with!

We’ll try to update you again with more information next week!