On Library Dependencies and API Evolution

As maintainer for publicly available libraries one sometimes has to answer feature requests or handle feedback about missing features of the library. How does one prepare for different requirements? I’d like to tell you how and why I opted to implement yet another docker http client on my own and I’ll also try to explain where I see its benefits and disadvantages. not invented here syndrome? You have probably seen several Docker remote api client libraries for different environments or programming languages.

Deploying with Gradle and Docker: have fun

Deploying products to production is a quite individual process for every application. Building deployment pipelines has already been described on a high level of abstraction, e.g. by the ThoughtWorks guys Jez Humble, Dan North and Chris Read in their paper The Deployment Production Line, not to forget the more general theme about Continuous Delivery being described in its own book by Jez Humble and David Farley. You might search for tools implementing the according patterns, and you’ll find some like ThoughtWorks Go (it’s free!

Gradle-Docker-Plugin and Docker-Client available

In line with our deployment pipeline written in Gradle and using Docker, we currently use Groovy’s process execution methods to talk with a command line Docker client. That way we make ourselves dependent to an installed Docker client on our CI servers. Since we don’t like to provide a bunch of specific CI servers, I started to implement a HTTP client for Docker, written in Groovy. The reason not to use existing Java implementations of such a Docker client was simply timing: some months ago the now completely rewritten Java Docker API Client wasn’t so well maintained than today… and, well, I like to play with new tools and wanted to explore the Docker remote API for myself.

Gradle Summit 2014

Great news: I’m going to speak at the Gradle Summit 2014 in Santa Clara. This will be the very first talk I’ll give in public so I’m quite excited! My talk will have two parts, with the first one about how we migrated a Maven multi-module project of 300 pom.xml files to Gradle. The second part will show you how we currently use Gradle in combination with Docker to continuously deploy a product of the EUROPACE 2 platform to production.

ProvidedCompile and Compile Dependencies with Gradle

When using the Gradle war plugin you’re enabled to declare providedCompile dependencies to tell the compiler to include those dependencies in the compile classpath, but to not make Gradle include them in the packaged .war artifact. Your build.gradle script might look like this, e.g. for a webapp using GWT: apply plugin: 'war' dependencies { ... providedCompile '' ... } The dependency shown in the example has some own dependencies, which can be shown by using the :dependencies task.

Using Compiler Arguments with Gradle

Just in case you’re searching for a way to use multiple compiler arguments in your Gradle builds, have a look at this snippet: subprojects { tasks.withType(JavaCompile) { options.compilerArgs << "-Xlint:unchecked" << "-Xlint:deprecation" } } I took the example from stackoverflow, but you can find details at the Gradle DSL for the JavaCompile class.

Using Coveralls in your Gradle build

Recently I stumbled over a tool Coveralls. It helps monitoring your test coverage. You can integrate it e.g. with your Travis-CI builds by using a plugin for your favorite build tool. Needless to say that they also provide Travis-CI similar badge to show off your current test coverage near your current build status in your README file at GitHub. Their docs sadly aren’t very focused on Java tools like Maven or Gradle, so you have to find a working plugin on your own (or code a new one by using the Coveralls API).

Gradle Debian plugin

A new Gradle plugin for creating Debian compatible packages (.deb) is available at Bintray. It allows you to package any files through a convenient Gradle build script configuration into a Debian package compatible file. You may also include your MavenPublications (.jar or .war) by only referring to their publication names. To use the plugin you need some knowledge about the package structure and configuration scripts. The Debian New Maintainers’ Guide, chapters 4 and 5, will help a lot.