If the vision one year ago of JReleaser, the release automation tool, was to manage releases just for itself, Andres Almiray, creator of JReleaser, didn’t expect that the customer base had slowly grown since then and the current releases of other projects were powered by it. kcctl, the command-line client for Kafka Connect, was perhaps the first early adopter of JReleaser. More recently, Gluon’s SceneBuilder added JReleaser to its build pipeline to create early-access releases of its binaries, the Quarkus CLI tool uses it to publish binaries to Homebrew and SDKMAN!, and JBang, the source of inspiration for many of JReleaser’s features, switched to using JReleaser as well.
Even though 95% of the code is still written by Almiray, contributing developers who adopted JReleaser to their own projects, provided feedback in the form of discussion topics, issues and tweets that have helped shape the features found in the recent release of JReleaser 1.0. To better understand the experience in adopting JReleaser for a project’s release management, InfoQ reached out to a few of these contributing developers.
JBang + Quarkus CLI:
Max Rydahl Andersen, distinguished engineer at Red Hat, started using JReleaser with the release of JBang 0.6 and recently adopted it for the Quarkus CLI. It was a good fit for JBang, as its release mechanisms also served as initial inspiration for JReleaser. And at the point when all the necessary install options were covered, it made sense to adopt it. For JBang, the JReleaser bootstrapping was trickier due to its specific needs. Nevertheless, the collected feedback meant Andres could improve its product. This was proven by the straightforward adoption by Quarkus CLI. JReleaser is configured at the end of a GitHub Action taking the artifact and taking care of the release chores. When asked about his assessment of JReleaser, Andersen told InfoQ:
Awesome. Something the Java ecosystem didn’t know they were missing. Not having to deal with the various installer differences but still be able to adjust to my needs. And at the same time probably 90% of Java CLI projects can get everything setup in minutes.
kcctl
Gunnar Morling, senior principal software engineer at Red Hat, uses JReleaser for multiple projects, the icebreaker being kcctl with JReleaser 0.6.0. The adoption allowed him to change a cumbersome and chaotic release cadence with a smooth and constant experience that allowed Morling to publish on the three mainstream OSs at once. During the bootstrapping phase, any hiccups were quickly fixed by Almiray in providing a new version. Due to the ease of the first onboarding, he started using it on the other two of his other projects: JFRUnit and oss-quickstart. On top of the releases deployed to Homebrew and SDKMAN!, Gunnar hopes to be able to release on Chocolatey in the future. When asked about his assessment of JReleaser, Morling told InfoQ:
[During the bootstrapping] It almost felt as if I had obtained the platinum support package.
Neo4j-OGM
Michael Simons, staff software engineer at Neo4J, introduced JReleaser 0.8.0 on Neo4j OGM after the successful adoption on kcctl. The bootstrapping required not more than an afternoon with Andres’ help. The sensible defaults supported by the detailed documentation ensured that all the platforms’ specific technicalities remained behind the scenes. Surprising, too, is the fact that the same level of functionality is available regardless of the way one uses the tool: either standalone or as a plugin of other tools (like Maven). With the templating mechanism, everything that gets generated, be it release notes, or integrations for packagers like Homebrew, Docker etc, is available as templates.
Another important point was that JReleaser can easily be adapted to a flow. In Simons’ case, he releases locally with the Maven release plugin publishing on Maven Central. This tags a release that, in turn, triggers JReleaser to run on GitHub Actions: it generates the release, builds native binaries, the changelog (with the binaries attached to it) and updates the JBang and Homebrew catalogs. When asked about his assessment of JReleaser, Simons told InfoQ:
It made me realize that conventional commits are a good way to think about producing a sensible changelog right from the start.
ConnectOffsetReset (ConnOR)
Oliver Weiler, senior software engineer at RTLPlus, started using JReleaser quite early with the release of ConnOR 0.5, a small CLI tool to reset the Kafka Connect source connector offsets. He was looking for a way to distribute his tool to multiple channels without the complexity associated with such an operation. Even though initially considered that such a tool would bring in more complexity than it was worth, it proved that JReleaser’s defaults allowed him to have a working configuration in a short period of time. Currently, his project is distributed to Homebrew, SDKMAN! and Scoop. In his opinion, the documentation could use some tweaking, as Weiler explains:
While great, it is sometimes hard to find what you're looking for. Other than that, I have nothing to complain about.
When asked about his experience with JReleaser, Weiler told InfoQ:
Want to release to GitHub? It’s a two-line configuration! Publish to Scoop? Also a two-line configuration. This is convention over configuration done right!
JReleaser seems to be the sum of all practices that Almiray has gathered through his own projects and discussions within the Java community. Besides, for now, Almiray provides assistance with the onboarding of new projects, fixing bugs and adding new features. Nevertheless, even if Almiray is still the main contributor, the Java community rallied to provide feedback that helped continuously improve JReleaser.
