Skip to content

Instantly share code, notes, and snippets.

@fmcarvalho

fmcarvalho/Maven-Central-Repository-cheatsheet.md

Last active December 27, 2023 16:52
Show Gist options
  • Save fmcarvalho/93b2da820c4b90b61170c9805991811a to your computer and use it in GitHub Desktop.
Save fmcarvalho/93b2da820c4b90b61170c9805991811a to your computer and use it in GitHub Desktop.
Download ZIP
Maven Central Repository deployment cheatsheet terminology
Raw
Maven-Central-Repository-cheatsheet.md

Maven Central Repository deployment cheatsheet

This is NOT a step by step tutorial guiding you on how to setup and configure your project to deploy artifacts to Maven Central Repository. There a couple of nice guides with detailed information about all setup requirements related with Maven, Sonatype OSSRH, Nexus Repository, Staging, POM, signing Your Artifact with PGP/GPG, etc.

Once you have enabled your deployment process, this guide aims to distil the core entities involved in that workflow.

Respositories

First of all let’s clarify the repositories terminology which includes 4 different repositories. Put it simply, they are:

Source Code Repository | OSSRH Staging ---> OSSRH Releases <--- sync ---> Maven Central Repository

  1. The Source Code Repository (e.g. Github) which in Maven POM (Project Object Model) is configured in the environment settings SCM (Software Configuration Management, “also called Source Code/Control Management)”)

  2. Staging OSSRH (Open Source Software Repository Hosting) (e.g. Nexus Repository Manager) which in Maven POM is configured under Distribution Management

  3. Releases in OSSRH. Successfully closing the Staging repository moves components into the Release repository of OSSRH

  4. Maven Central Repository is a repository of software components providing an easy way to access and distribute libraries between developers. Once in Release repository of OSSRH the components will be synced to the Maven Central Repository.

My workflow

My deployment workflow includes 6 steps. Off course, I could simplify it and automatize some steps. However this is my compromise between control and automation. This means, I do not want to have it completely manual, but I do not want it fully automatic either. So this is the way it gives me some control with less effort and transparency over each step. These steps include:

  1. mvn release:clean
  2. mvn release:prepare -- Creates release artifacts with corresponding git tag version (e.g. 1.1) and setup next Snapshot version (e.g. 1.2-SNAPSHOT) in POM. Push master and tag to origin.
  3. git push origin <release tag> -- Pushes the release tag (e.g. 1.1)
  4. mvn release:perform -- Executes the following 2 steps and removes file release.properties.
1. `git checkout` to previous commit corresponding to release (e.g. tag version 1.1).
2. `mvn deploy:deploy`  -- push artifacts to Staging OSSRH.
  1. Search by the Staging repository in Nexus Repository Manager and close it by pressing the Close button, which will trigger the evaluations of the components against the requirements.
  2. If the Staging Repository was successfully closed in step 5. then release it by pressing the Release button.
  3. git checkout again to 1.2-SNAPSHOT

After these steps the components will move into the release repository of OSSRH where it will be synced to the Central Repository. Note that according to documentation

Upon release, your component will be published to Central: this typically occurs within 10 minutes, though updates to search can take up to two hours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment