Uploading Snapshots and Releases to Maven Central with TravisCI
As a passionate developer I always strive to optimise my build chain for speed and simplicity. In this example I’d like to publish a library on maven central without any onsite build tooling except my IDE. So lets see how to get rid of gpg key management and implement a trivial push-button release process with Github and TravisCI.
Add build plugins for binaries, javadoc and sources jar files
and gpg signing
(Creation of a gpg key and signing your builds is done implicitly)
Integrate this with travis secured environment variables
Add general information to your pom.xml
You need to add the following parts to your pom.xml. There are
detailed explanations of these configuration values at
This general information needs to be available (e.g. a missing
description tag will make deployment to maven central impossible):
Also the developer and license information is necessary:
Add distributionManagement for ossrh to your pom.xml
The following two entries are given to you, as soon as you finish step
1 and 2 at sonatype’s jira:
You will need to add them in your pom.
Once set up, the maven deploy task will know the target for uploads.
Add maven build plugins
For a successful upload to maven central you need your jar, a java doc
jar, a java sources jar and all of those need to be signed with a gpg
key. The following configuration in your pom.xml will take care of
We create our temporary GPG-Keys on-the-fly with the following script (.travis/gpg.sh):
This will provide maven with a key pair to sign our artifacts.
Signing is mandatory with sonatype.
Create a settings.xml for the travis build
The following settings.xml should be available in your git repository at
As you can see we’ll use environment-variables to configure passphrase
and sonatype password. (Those are tokens, not your real account passwords. See below.)
Add the secrets to your Travis Settings Page
If your project is already on travis, you need to add the environment
variables on the settings page. For example, for the logback-redis project
under idealo namespace, the url looks like this:
Fill SONATYPE_USERNAME and SONATYPE_PASSWORD with your tokens (NOT your actual credentials).
Your .travis.yml file could look like this:
It’s very important to override the install instruction for mvn with
--settings .travis/settings.xml, otherwise your settings.xml will be
ignored and the configuration would be useless.
Since it’s easier to read if you have all deploy steps in a separate
file, I created a .travis/deploy.sh for this:
This snippet sets the version in the pom file to the tag version (if
it’s a git tag aka release). Afterwards a deploy will be triggered only if it is a release.
That’s why in my pom.xml there is always a -SNAPSHOT qualifier
and no final MAJOR.MINOR.PATCH version, yet. This part takes care of
creating a SemVer version of the pom.xml.
If you set this up correctly, your setup will work like this:
In your pom.xml you have <version>0.1.0-SNAPSHOT</version>
If you push a commit to master of your repository only the tests will run.
If you git tag 0.1.0 and git push --tags afterwards, you will
have 0.1.0 of your library available at maven central.