Adopting JReleaser

According to its website, "JReleaser is a release automation tool. Its goal is to simplify creating releases and publishing artifacts to multiple package managers while providing customizable options.". That is the original goal of the tool since its inception in November 28th 2020 and that goal continues to be the main driver behind features and fixes added to the tool. However, in order to support this driver a few things were added along the road, things that have led people to adopt the tool for other reasons. Here's what has happened so far:

1. Publish to Package Managers

The need to publish a distribution to a given package manager such as Homebrew, Scoop, Chocolatey, and others (see the full list of supported package managers). Most package managers require additional metadata files (such as Ruby formulae, JSON or XML manifests) that can get tricky to craft for beginners. JReleaser abstracts the complexity of writing such files by leveraging Convention over Configuration and file templates.

Many of these package managers share common traits and require similar data that may be configured at a single location, making it a snap to configure additional package managers for a given distribution. Now, package managers often require a publicly available URL from where to download distributions. There are a few options out there but perhaps the most common is to download files as git release assets, which brings us to the next adoption driver.

2. Git Releases

It's natural for projects to tag a release and create a "git release" page. Git services such as GitHub, GitLab, and Gitea support this concept.
It's common practice to add some sort of release notes to the git release page. These release notes may be hand crafted, but they can also be auto generated based on commit messages. This is where JReleaser shines again as it provides a series of configurable rules that can turn commit messages into readable, user friendly release notes.

If you happen to follow the conventional commits specification for commit messages then it's just a matter of turning on a single configuration setting to transform your commit messages into the following:

Additionally to this, JReleaser may also tag and comment on issues related to a given release, which will send a notification to its author letting them know the fix has been shipped! Moreover, if you would prefer other options than (or additionally to) a git release page to publish release artifacts then the tool has you covered with a wide variety of services.

3. DeployMent to Maven Central

The most asked feature since the tool's first release posted on April 10th 2021. JReleaser being a release tool made sense to also support deploying artifacts to Maven Central during a release. The team decided against doing so because this behavior was already covered by Maven and Gradle. However, configuring each build tool to perform such feat takes a few tries to get it right. In the end we decided it was a good idea to provide such feature and boy was it the right choice, the number of downloads for both the Maven and Gradle plugins went up from 20K to almost 80K in a couple of months in 2022 and have been up ever since.

JReleaser can verify many of the rules applied to artifacts as required by Maven Central (thank you Pomchecker!) before a single artifact is pushed to the remote service. This reduces the number of failed releases as you can run these rules in a local environment until you get all of them passing.

If you already have experience publishing artifacts to Maven Central then this guide should be enough to get you started with a migration if you feel like doing so. On the other hand, if you're new to this and would like to get started then I recommend reading Maciej Walkowiak's How to publish a Java library to Maven Central - Complete Guide.

Adding this feature was indeed a good idea as witnessed by this reddit post

4. Distribution Assemblers

This is perhaps the least common adoption driver (at the moment) but I hope it becomes more popular in the future. Assemblers have a single goal: create a distribution that may be passed on to package managers, uploaders, and releasers. Typically you'd use assembly support provided by your build tool of choice. JReleaser goes one step further than your run of the mill build tool plugin by making sure archives are reproducible, but your build artifacts must be reproducible as well, the onus is on you in this regard.

Once again, assemblers rely on the fact of shared data and common data just like package managers. Configuring a Jlink assembler (for bundling a custom Java Runtime) followed by native installers (via Jpackage) is quite a straight forward task for example. Additional assemblers such as .deb and .rpm may be available in the future. Such assemblers won't rely on the jpackage command and thus will be able to package non Java distributions.

Summary

Overall the tool continues to grow in popularity as it solves a series of problems many developers face when performing releases. The following badges show the number of downloads per service (at least those supported by shields.io):