Skip to content


Deploying to OSSRH with Gradle - Introduction⚓︎

Just like Gradle can be easily configured to consume components from the Central Repository, it can be configured to publish to OSSRH.

Metadata and Signing⚓︎

In order to deploy your components to OSSRH with Gradle, you have to meet the requirements for your metadata in the pom.xml as well as supply the required, signed components.

The maven plugin for Gradle can take care of the metadata, generate the required pom.xml file as well as take care of the deployment of the build output to the repository. The signing plugin allows you to get the components, created by standard Gradle tasks, signed:

apply plugin: 'maven'
apply plugin: 'signing'

Jar Files⚓︎

For a typical Java project you can add a javadocJar as well as a sourcesJar task

task javadocJar(type: Jar) {
    classifier = 'javadoc'
    from javadoc

task sourcesJar(type: Jar) {
    classifier = 'sources'
    from sourceSets.main.allSource

and hook them up into the artifacts collection together with the project jar itself:

artifacts {
    archives javadocJar, sourcesJar

Signing Artifacts⚓︎

The defined artifacts can be signed with

signing {
    sign configurations.archives

Metadata Definition and Upload⚓︎

To prepare for the actual upload, you have to define all the metadata with the help of the maven plugin. Group and version are set within the top level project, while the artifactId is configured for the archiveTask.

group = "com.example.applications"
archivesBaseName = "example-application"
version = "1.4.7"

The generated pom file has to be signed and all signed artifacts then have to be uploaded. All this can be configured as part of the uploadArchives configuration.

Note: As of February 2021, all new projects began being provisioned on If your project is not provisioned on, you will want to reference the legacy host

uploadArchives {
  repositories {
    mavenDeployer {
      beforeDeployment { MavenDeployment deployment -> signing.signPom(deployment) }

      repository(url: "") {
        authentication(userName: ossrhUsername, password: ossrhPassword)

      snapshotRepository(url: "") {
        authentication(userName: ossrhUsername, password: ossrhPassword)

      pom.project {
        name 'Example Application'
        packaging 'jar'
        // optionally artifactId can be defined here
        description 'A application used as an example on how to set up
          pushing  its components to the Central Repository.'
        url ''

        scm {
          connection 'scm:svn:'
          developerConnection 'scm:svn:'
          url ''

        licenses {
          license {
            name 'The Apache License, Version 2.0'
            url ''

        developers {
          developer {
            id 'manfred'
            name 'Manfred Moser'
            email ''

The dependencies from your Grade project will be inserted into the generated pom file.


The credentials for signing and upload can be stored in your file in your users home directory. The content would look like this



Do not use your login username and password in settings.xml

Please do not use your UI login username and password in settings.xml. Use the token that was previously generated.

The official Gradle documentation for the Signing Plugin, excerpted below, provides guidance for the values of the first 3 fields:

  • The public key ID (The last 8 symbols of the keyId. You can use gpg -K --keyid-format short to get it).
  • The passphrase used to protect your private key.
  • The absolute path to the secret key ring file containing your private key. (Since gpg 2.1, you need to export the keys with command gpg --keyring secring.gpg --export-secret-keys > ~/.gnupg/secring.gpg).

These items must be supplied as the values of the signing.keyId, signing.secretKeyRingFile, and signing.password properties, respectively.


With this configuration in place a deployment can be started with

gradle uploadArchives

Releasing the Deployment to the Central Repository⚓︎

Once the deployment is completed, you can proceed to manually release your components.

Alternatively you can use a setup using the Nexus Staging Ant tasks wrapped in Gradle to automate the interactions with the staging repository. An example can be found in the Nexus Repository Manager documentation examples project. Using the Gradle Nexus Staging Plugin can achieve the same automation.

Both approaches allow a fully automated release of components via OSSRH to the Central Repository.