Pushing AARs to Maven Central
Table of Contents
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:
- 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.
- maven-publish. The new way to upload artifacts, currently being incubated. While this plugin looked great it seems to only support
webprojects. It also requires you to modify the
pom.xmlas XML rather than a object which means no value checking.
- 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
- 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
snapshotsupport 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
- Automatically selects which repository to upload to (snapshot/release).
pom.xmlvalues from the project’s
It is also exteremely easy to use, it just requires the following line to be added at the end of your
apply from: '../maven_push.gradle'
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.propertiesfile which controls which keystore to use to sign the APK ( example).