Adventures with Gradle: Getting Flyway to Work with CockroachDB

For any JVM developer a build automation tool is your best friend, and at Radio Africa we use gradle. The thing about true long lasting friendships is that fights can and will happen from time to time. Sometimes we even feel betrayed by the people we are closest to and that, sums up my relationship with this thing called gradle. This is the first ‘adventure’ I’ve chronicled and as you’ve probably figured from the title, I’d like to make this into a sort of series. And this first one is about how I got the above to work.

Let me explain the situation first, we are experimenting with CockroachDB and we use flyway extensively and want to continue using it. CockroachDB 2.0 is going to be supported in flyway 5.1 but that has not been released yet, although it is on the master branch. Since flyway is open source we thought “hmmm… let’s build it for ourselves and try” . And that is where my latest spat with gradle started.

So here I am never made a gradle plugin before, but need an easy way to use one that’s built from source across multiple projects. Also this wasn’t just for me, so it had to be simple enough for everyone at the office to use. Here is what I went through.

Building flyway with jitpack.io

In case you’ve never heard of or used jitpack.io, it is a free service that builds and serves jvm projects like maven central from any public git repository (you gotta pay for privacy). So I thought, “Let’s build flyway using this — make our lives simple”. But since this article doesn’t end here you can tell it already didn’t work. This is because flyway requires java 9 to build and jitpack needs to know this somehow in order to build it properly. Kudos to them since they’ve made it easy, just create a jitpack.yml and add it to the root of the repository you wish to build with java 9 like so:

So I added this to the flyway repo we had already forked and voila, it built on jitpack. At this point I thought I was done. I’d just include it and it would work. Obviously this didn’t work despite my joy, I’m sure if I configured it properly it would but using this was supposed to be a drop in replacement for the current setup. I felt like gradle had made a false promise even if it wasn’t gradle’s fault. At this point I thought why not temporarily have our own version on gradle plugins, that should simplify everything.

Hosting flyway on gradle plugins

Two things here, I did not want to interfere with the flyway codebase in any way whatsoever and I had to use the gradle publishing plugin. To achieve this I started a new project, and pulled the flyway I built on jitpack.io as a dependency, and because inheritance, I just extended the FlywayPlugin class like so:

So elegant.. I ❤️Kotlin

An in order to publish this to gradle plugins, I needed two more things, a properly configured build.gradle, and the obligatory property file that points to the class that houses the plugin.

So this was how I configured my build.gradle — a few things are left out but more or less this was it. The “// …” represent fluff that has been left out. Whatever’s included is what you would add to your gradle file.

The final piece is the obligatory properties file that matches the id of your plugin. You would need to place it in your resources folder, so this would be in ‘src/main/resources/META-INF/gradle-plugins’ according to gradle documentation. So in this case our file would be called: com.radioafricagroup.plugins.flyway.properties

And the implementation class should be the class we made earlier on, the one that extended flyway’s plugin class.

Why do all this you’d ask? It’s simply because flyway use maven and through thick and thin I shall stand by gradle.

Publishing the plugin

Simple create an account on gradle plugins, get your API key and secret the image below is from the gradle plugin docs and I think it sums up how to setup your credentials beautifully.

Then run the publish command:

./gradlew publishPlugins

And that’s it.

Using the plugin

If you trust us and would like to use flyway’s master branch, feel free to use our plugin. Just add jitpack to your buildscript dependencies and include the plugin like you usually would. Like so:

Of course we won’t maintain it, we just couldn’t wait to have flying cockroaches. So it’s imperative you switch to 5.1 of flyway as soon as it is available.

UPDATE: flyway v5.1 is now available, please don’t use this any longer 😄