April 10th marks JReleaser's second birthday! And I couldn't be happier. The project has grown a lot since that fateful afternoon when Max and I were chatting on different options to release projects. It went down like this: Max spent a lot of time and energy getting JBang's release process up to a point where he was happy with it, and I needed a way to replicate the same for Ikonli but was not looking forward to the amount of work required to make it happen. Instead, I wished there was a way to automate as much as possible, just as I did for gum using GoReleaser. Once I explained to Max how it works it was clear that we both longed for a tool like GoReleaser, except that GoReleaser only works for Go projects, not Java.
This is when Max nerd-snipped me and JReleaser was born. And boy, that rabbit hole went deep!
The first release provided support for a handful of distribution types, package managers, and announcers. The list of integrations has grown as well, including CI/CD services. What began as a Java centric project (the project name starts with a "J" for obvious reasons) it has widened its reach to non Java projects. There are fully working examples for Ballerina, Cpp, C#, Elixir, Haskell, Perl, Rust, Swift, and Zig. More to come in the following weeks.
The project wouldn't be what it is today without all the people that has contributed to it. Shout out to our contributors, early-adopters, sponsors, and everyone else that has helped. You rock!
In terms of adoption we keep track of artifacts downloads from the project's GitHub releases. These downloads come from different consumers: direct downloads, the jreleaser/release-action GitHub Action, package managers such as Sdkman, Macports, Scoop, Homebrew. We've reached 20k downloads across all releases which is a pretty good number for running the tool as a CLI.
However, the tool may also be consumed as a plugin for either Maven and Gradle where the number of downloads turns out to be higher.
Adoption continues to rise. I've spotted 3 main drivers:
- Publish binaries to package managers.
- Publish Git releases with formatted changelog/release notes based on commit messages.
- Deploy artifacts (JARs, POMs) to Maven Central.
Publish binaries to package managers. This is the original goal of the project. No surprise those developers that found themselves in the same situation described at the beginning of this post would give the tool a try. As far as I can tell the majority of projects that follow this adoption path publish CLI binaries, with only a few opt for publishing desktop applications.
Publish Git releases. Things get a bit interesting on this one. In order for package managers to provide artifacts to be installed said artifacts must be available from a remote resource, typically a publicly available URL. A Git release page is the natural candidate as the hosting service (GitHub, GitLab, Gitea) provides support for it. A Git release page may or may not contain release assets (binaries) but it would be great if it provided a text representation of the changes (changelog) or a curated piece of text (release notes).
Given that JReleaser had to create a Git release page might as well create a changelog while at it. But listing all commit messages from the previous tag to the latest looks dull; it would be better if commit messages could be categorized and embellished with more details.
Applying your own commit message conventions or following existing ones (conventional commits, gitmoji) makes it easier to categorize and format the changelog
Deploy to Maven Central. This was the most requested feature since JReleaser's first release but we hesitated in adding it since both Maven and Gradle already provided this capability. Once it became clear how this feature could be added we made it happen (in 1.3.0) which resulted in a major adoption bump. The project's website provides examples for both Maven and Gradle. There are also other guides such as How to publish a Java library to Maven Central by Maciej Walkowiak, and How to Release a Java Module with JReleaser to Maven Central with GitHub Actions by Jago de Vreede explaining with additional detail how this feature may configured in your project.
There's a dormant 4th adoption driver: assemblers. Currently there are 5 assemblers supporting Java based projects. In particular, the Jlink assembler enables the creation of cross-platform Java Runtimes with jlink, Jpackage greatly simplifies creating platform installers, Native Image aids in generating platform specific executables, while Java Archive can create binary distributions. All of them make it trivial to work with modular and non-modular Java codebases, something that requires a bit more of work if using Maven or Gradle plugins. Additional assemblers such as .deb and .rpm (for Java and non-Java projects) are in the roadmap.
Roadmap
The last point leads us to things to come. Our issue tracker already has a list of items that we'd like to see addressed in future releases. Things like additional package managers (AUR, APK, etc), assemblers, Git services (o hai Bitbucket!), among others. We're also keeping track of breaking changes that will be added to v2 when the time is right.
As always, feedback is welcomed, feel free to file a ticket or start a discussion topic.
Keep on coding!
Photo by Adi Goldstein on Unsplash
