Chris Banes


I work as a DPE in the Android Developer Relations team. This is my personal blog and any views expressed here are mine, and not my employers.


Pushing AARs to Maven Central

Over the past few weeks I've been updating ActionBar-PullToRefresh for the release of v0.7, but have been a bit blocked on publishing the library as an Android Archive (aar) to Maven Central. It was the number one issue/request that I received, and while I had a working local Gradle build I could not find an easy way to publish the results.

There a few solutions out there but nothing really definitive. The main solutions I found were:

  1. upload task. The original Gradle-provided method for uploading archives, provided as part of the 'maven' plugin. This seems to have been superseded by number 2.
  2. maven-publish. The new way to upload artifacts, currently being incubated. While this plugin looked great it seems to only support java and web projects. It also requires you to modify the pom.xml as XML rather than a object which means no value checking.
  3. gradle-nexus-plugin is a third-party open source plugin which is designed to work on top of solution number 1, but does a lot of work for you. Unfortunately it only seems to work with java projects.
  4. mvn-repo a specialized script provided by +Koushik Dutta which again works on top of solution 1 but specialised for Android. Unfortunately it doesn't have snapshot support and requires a GitHub API key which I didn't want to setup.

So as you can see, it's not exactly easy.

Noob and proud

Before I go any further I must say that I am a Groovy and Gradle n00b so my solution below may not be optimized.

My solution

As we had a long weekend in the UK this week, I decided to spend a bit of time creating a easy to use solution for myself.

The first thing I decided was that I was going to re-use mvn-repo and customize it to my needs. The great thing about mvn-repo is that it is basically a Gradle script, which gets called from your project's build.gradle to say: 'hey, upload me!'. This means you can be selective on what projects get uploaded and you can re-use as much boilerplate as possible.

The downsides to mvn-repo were that it drags in a lot of information from GitHub to include in the pom.xml. While this is great for some projects, I wanted much more control of goes into the pom.xml. After reading some of the Gradle User Guide I stumbled upon the use of properties files which allow you to seperate out any configuration values from your scripts. A eureka moment quickly followed when I realised I could combine a re-usable 'upload' script with project specific property files, hence keeping my build.gradle scripts as clean as possible.

The result...

The end result is maven_push.gradle which is a modified version of mvn-repo:

  • Automatically selects which repository to upload to (snapshot/release).
  • Imports pom.xml values from the project's gradle.properties (example).

It is also exteremely easy to use, it just requires the following line to be added at the end of your build.gradle (example):

apply from: '../maven_push.gradle'

Extras

I have used the properties files for a number of other things in the project:

  • The version number and name is now controlled in one place: the root gradle.properties. These version values are applied throughout the project, including the built sample APKs.
  • Each application project has a private signing.properties file which controls which keystore to use to sign the APK (example).
comments powered by Disqus