Welcome to

Evaluate Expression

Home / Gradle / Releasing a Gradle project, start to finish

Releasing a Gradle project, start to finish

I recently released my first piece of software. A very simple tool which provides a fluent API for producing a table of stats, called TableWriter.

I am now working on Westie, a suite of static analysis tests which can be customised per project. It can already enforce the structure of comments (e.g all comments must have contain TODO and a date), restrict imports to certain packages, so as to follow a clean architecture, and ensure that comments referencing a Jira ticket aren’t already in the testing phase so as to not forget leftover work.

To release TableWriter I had to pull together a lot of information from the web. Some was out of date, other parts missing. So I’m going to write an up to date, start to finish guide as I go through the process of releasing Westie.

Before your code is ready to be released to Sonatype it must first be documented. Start by adding a license file and a notice file to your repository like I have done for TableWriter. Notice.txt will need the copyright information and project name replaced with your project specific details.

All public methods you intend to be used will require javadoc documentation. If you haven’t seen this before they are comments which follow this format:

Popular IDE’s will generate the format for you if you start typing /** above your method or class definition. Note that all parameters, return types and thrown exceptions require documentation.


Our build.gradle file is where most of your configuration will go, assuming to have a working file already, start by adding these tasks:

javadocJar and sourcesJar do as they suggest and produce the necessary jars. The first will be used to provide your documentation of your code and the second is the code itself.

We also need to specify the group and version of the application, replace the value for group with your desire id, I would recommend the pattern of “io.github.yourGithubUsername“:

The next addition to your gradle file is:

This defines what will be packaged up and released.

Next we’ll add the necessary plugins:

Now we will define the process of signing the repository, which is a necessary step in any release.


We can now sign up to Sonatype, do so here. Next make a ticket for your new project, note that you may be asked to log in. For GroupId in the New Project ticket form, use the same value for group that you used in your build.gradle file.

I found this video helpful for this process.

Make a note of the url for your open ticket for your New Project. Keep checking back until it has been approved.

In the meantime we can add the uploadArchives task, which is what we’ll run to release the project.

You can see a complete example in my TableWriter project’s build.grade file. Remember to update the pom.project values such as your developer details (you can present multiple developers here) and the scm details.

The values for sonatypeUsername and sonatypePassword in your uploadArchives task will be picked up in your gradle.properties file. If you don’t have one already, created a gradle.properties file in your .gradle/ directory, which should be in your home directory.

Add the following lines:

The values you provide should match your log-in credentials you used to sign up for Sonatype.


Now we’re ready to sign the repository. We need to download the GPG tool, I recommend downloading the latest version as this will be the most up to date and secure. We’ll be using GPG to sign the repository. With this signing, users of your project will be able to verify that what they expect to download is what they’ll receive, and not something malicious instead.

First check that you have download version 2 of GPG.

Start by typing into your command line: (you may be prompted to add sudo to the start of your command)

You should see in the output:

Here you can see I am using version 2.1.15.


Now to generate the key, use:

Follow the prompts for your name, key size etc.

When you are done you can view your key(s) with the command:

The output will be along the lines of: (make not of your key, which will be in place of the XXX’s)


For the gpg2 generated key to work with the maven deployment plugin we are using as part of the uploadArchives task, we need to add a few things first.

Version 2 of GPG no longer produces the secring.gpg file. We are going to add it as it’s necessary for the deployment.

Like your .gradle/ directory in your home, you should now have a .gnupg/ directory. Running this command will create the necessary file. Replacing the XXX’s with your key, visible from the –list-keys command.


We’re now ready to update the gradle.properrties file in the .gradle/ directory. The file should now look like this:

signing.password is the password you created whilst running gpg2 –gen-key.
signing.secretKeyRingFile is the full path to the secring.gpg file we just created.

The signing.keyId property expects an 8 character long keyId. As you may have noticed your generated key is 40 characters long. After some digging around online I finally came across the answer and luckily the solution has been considered as part of gpg2.

This command will list your keys in the short format, allowing us to reference a short version of the keyId in your gradle.properties file.

The output looks like this:

The value in place of YYYYYYYY is what you’ll want to reference as the value for signing.keyId in the gradle.properties file.


Assuming you have had a response on your Sonatype ticket from Central OSSRH, we’re now ready to run the gradle uploadArchives task.

Once uploadArchives has run successfully we can view the release on the Nexus Repository Manager. The log-in details are the same as those you registered on the Sonatype website when submitting a ticket.

Once logged-in, navigate to the Staging Repositories page. Find your repository in the table at the top of the page, the naming strategy will be your groupId followed by an incrementing number, per release, starting at 1000.

Here we can see my first release of Westie with groupId “io.github.tjheslin1”. The number is already at 1007 as I have I already released TableWriter under the same groupId.

westie_release_nexus

If you need to make any changes to the release, select your repository and then click “Drop”. This will remove this release so you can submit another after making your changes and re-running gradle uploadArchives.

Otherwise if you’re happy you can click “Close”.

Selecting the repository will show information about the release below the table. Next to Activity you will see either a green tick or a red cross, indicating the validity of the release. It may, for example, complain if you are missing any fields in your javadoc. You will need to fix the complaints and then “Drop” and re-release.

Once a “Close” is successful you can now click “Release”. Once released make sure to update your Sonatype ticket, commenting that you have released your repository. I simply commented my ticket with “This has been done.”.


And we’re done. Soon your project will appear in The Maven Central Repository, you can search for it by the project’s name or by your groupId. Once it appears it can start being imported! Navigating to a specific version of the project in the Central Repository will provided dependency information which will show the pom.xml <dependency> details and the equivalent for other build tools.

From here on when you want to update your project, remembering to update your javadoc, simply increment the version of your project in your build.gradle file and re-run uploadArchives. A new release will appear in The Nexus Repository Manager which will require only Closing and Releasing.

Your GPG key can be reused for any future projects you intend to release, so most of the leg work has been done.

2 thoughts on “Releasing a Gradle project, start to finish”
  1. Jasper Keech February 12, 2018on9:33 am Reply

    Great blog post Tom, gonna be releasing soooo many grade projects now.

  2. Saz February 12, 2018on6:57 pm Reply

    Wow, so nice to read this, it really helped me!

Leave a Reply

Your email address will not be published. Required fields are marked *

Thanks for reading!

>> <<