April 2022 marks the one-year anniversary since JReleaser was introduced to the Java community. After a year of a steady two releases per month, Andres Almiray, creator of JReleaser, celebrates this anniversary with the rollout of version 1.0. During this time, support for other platform packagers was added: Macports and GoFish. Support for additional package managers will likely be added in the future.
During the past months, the tool has been picked up by other projects to craft their releases, mostly those using GraalVM Native Image for generating platform-specific binaries.
Even though the Java community has provided numerous open-source contributions to JReleaser over the past year, Almiray continues to be the driving force behind it. InfoQ reached out to Almiray to further understand how JReleaser has evolved.
InfoQ: Hello Andres, one year has passed since our last chat, in April 2021, when you had just launched JReleaser. Now you are rolling out version 1.0. What has changed during these months since we last talked?
Andres Almiray: To begin with, JReleaser expects binaries to be built and assembled by your build tool of choice. Early on we noticed that there’s an overlap with binary distributions created with jlink, jpackage and GraalVM Native Image. Thus we added support for those tools as part of the assembler step which is supposed to be invoked separate from the release step, giving you the option to invoke assemblers as many times as needed, or under the right circumstances, such as on a specific operating system as it’s the case for jpackage and native image.
InfoQ: JReleaser’s assumed mission is "publishing artifacts to multiple package managers." Can you please explain if and how JReleaser helps with other build targets, such as WAR/JAR files, Docker images or Kubernetes? Any other?
Almiray: JAR files, as the typical packaging and deployment target for Java binaries, are sometimes a self-contained application that might include all its dependencies, and it’s configured to be executable as well. Homebrew and Scoop support this packaging option from the get-go, others require additional files such as launcher scripts or a binary executable (JReleaser’s template mechanism and packager support fills in this gap).
JARs can be shipped with a Docker image JReleaser providing options for creating Dockerfiles based on templates.
There is no explicit support for WAR files or Kubernetes for the moment.
InfoQ: The name is heavily rooted in the Java environment. Does JReleaser support non JVM-related programming languages and build tools?
Almiray: That is correct. GoReleaser served as inspiration for JReleaser, thus not just the behavior of the former tool was mimicked but also the moniker, hence JReleaser (Release4J being another option). However, given its flexibility, it’s possible to release any kind of project.
For example, you can release Rust binaries: the usual Cargo build workflow produces the binaries, hook those with JReleaser and create a release. A blueprint for releasing on MacOS (Intel and ARM), Linux (Intel and ARM), and Windows (Intel) binaries compiled from Rust can be an inspiration for any programming language (Rust, Python, Perl, JavaScript, etc.) that produces binaries or not.
InfoQ: In retrospect, is there anything that needs to be changed? What does the future hold for you and JReleaser?
Almiray: Perhaps a more inclusive name (Releasy is an option for now) in version 2 to emphasize that the tool may be used with any project regardless of its source code.
Among the ideas floating around: integration with other platform packagers such as Flatpak or AppImage; ship native executables of the tool with GraalVM Native Image; and Integration with BitBucket and Azure DevOps.
In the current Java ecosystem, JReleaser seems to be unique, according to Almiray, as being the only one having all the required actions under the same umbrella. Even though prefixed with the "J" typical to tooling focused only on the JVM ecosystem, JReleaser promises to be able to work with projects written in other programming languages and perhaps a more inclusive name will come in its second version.