JReleaser: quick and effortless way to release your project
jreleaser.org
jreleaser.org
https://github.com/NJAldwin/maven-central-test
I wanted to release a jvm lib on Maven Central -- which no longer requires opening a jira ticket for a new package! Instead, simple DNS TXT verification is all that's needed. However, the caveat is that it's the new Maven Central service, which doesn't have as much support in build tools as the older sonatype one. jReleaser is one of the few tools which supports it.
So I hacked together a fully self-contained minimally reproducible example of a Gradle library, built and published in GitHub using jReleaser.
There were several things that had me scratching my head with jReleaser, and the docs are strangely organized IMO (it comes from supporting so many facets, I believe), but it ended up working well enough!
I ended up adding a doc build and some other stuff to the repo too. Now I have a full example that I can use to trivially publish new libraries (such as in-progress https://github.com/NJAldwin/ambient-consumer ).
(Why Maven Central? Since the demise of jFrog/jCenter/BinTray, there's not been an easy way to widely publish jvm libraries. At work I've used GH packages, but that requires a GitHub login even for public packages, which is a significant barrier IME. JitPack is one option, but it does on-demand builds linked closely to the origin repo, whereas I wanted the classic immutable build published on release.)
A big shout-out to Andres Almiray, the maintainer of JReleaser, who has always been super-fast to answer any questions and help to sort out issues when I ran into them.
Would this be a simple lift and shift job to move to JReleaser (as it seems like it just uses jpackage behind the scenes)? With jpackage, if you want to create a Windows exe, it needs to be built on Windows. Similarly, build dmg on Mac and deb for Linux. Does Jreleaser also require this?
[1] https://docs.oracle.com/en/java/javase/22/docs/specs/man/jpa...
Now we have MacOS ARM, MacOS x86, Linux ARM/x86, Windows ARM/x86.
Even for a basic "cross platform" Java program (that bundles the JRE), that's 6 installs, which ostensibly need to be built on their respective platforms. Add on to that if you using something that includes a binary (like, say, SQLite, much less JavaFX which I work with).
The release burden is, well, frankly, daunting for a small project.
My honest thinking for my next project release is simply to tell folks to install the JDK, download the source code, and have them run:
./mvnw javafx:run.
That'll download all of the stuff it needs including the Maven runtime and all of the libraries, as appropriate, build the project, and run it. It's Fast Enough (maybe it's awful on a small RPi, I dunno).
When I get more than 5 downloads, folks can vote as to which installer to work on.
Creating the executables was quite the black hole. I didn't create one for Linux because I honestly didn't know what packaging scheme to use.
In theory, the CI infrastructure on GitHub will let you build on different platforms, yet another black hole of time to sink into.
So, yea, at least initially, I think the maven wrapper will be my "release model". SHOULD be pretty simple.
Presumably the major issue in distributing JavaFX applications (or most Java 9+ applications in general) is dealing with jlink. That leads to the problem in question: having to create N * M executable blobs, where N = # of operating systems and M = # of CPU architectures.
Yeah, seems to work for games well enough. Ship uberjar + small wrapper shellscript for Linux/macOS, .bat for Windows. Should work everywhere*
You don't need to do JLink for JavaFX. FX requires binary libraries, but you can make "platform specific" uber jars (and, probably, generic uber jars) that bundle correct libraries.
SQLite bundles all of the platforms into a single jar file, for example.
But that's another reason, at least for me, to look at the maven wrapper. Maven will "download the right thing" and not "burden" folks with copies of libraries they don't need. FX binaries can be quite big, particularly if you include WebKit (which I do simply for easy in app documentation, it's just a fat pig of a dependency though).
SnapCode: https://www.jdeploy.com/~snapcodejava
Because JReleaser is a release tool and not a build tool you are free to build however it’s needed, collect all artifacts and release them. I do this for the Ikonli JavaFX browser: build the app with Gradle which bundles platform specific JARs, then release them with JReleaser.
https://github.com/kordamp/ikonli Shows how it can be done. Requires building with GH Actions in multiple platforms.
For a "cross platform, portable system" it was just...ugh.
These are hobby projects. I struggle enough to make progress on them at all, much less dealing with tooling and what not (which I do not enjoy). Since my last project was a smashing success (I think 2-3 people downloaded it), it makes that extra hurdle to get installers working that much less interesting to me.
My next project I can leverage the work I did on my last one, to lower the burden. But clearly I would need to look into Github Actions (which I know nothing about) to get the cross platform binaries for machines I do not have. For my last project I installed Windows and Linux VMs to do my builds.
This JReleaser looks compelling, and maybe will make that kind of thing even easier with their examples.
Maybe my next project will be compelling enough to its audience to generate more traffic to justify the packaging effort.
Conveyor is free to use for open source projects and works how you'd hope it works: it's a signup/account-free downloadable CLI tool. You run a single command from your dev laptop (or a cheap Linux CI worker) and it builds/signs all the packages for every target OS and CPU architecture in one go, uploads them, and integrates the app with a native auto update engine. Sparkle on macOS, MSIX on Windows, an apt repository for Debian/Ubuntu users. It'll even make a download HTML page for you that detects the user's platform and gives a big green download button.
There's a bunch of sample apps showing how to integrate it into your {Electron,JavaFX,Compose for Desktop,native} app. "conveyor generate javafx my-sample-app" will spit out scaffolding that uses Gradle, and there's a Gradle plugin to import all the build info into Conveyor too. End result is you do:
./gradlew jar && conveyor make copied-site
With its large user base, I would have expected Java to have figured out all the details and offered users a single command-line tool that automatically builds the project into installers. I had adventures with relatable pain points when figuring out how to distribute Julia's GUI applications.
Another upcoming difficulty is transitioning to distributing applications that run in the sandbox. Windows has MSIX, Linux has Snap and Flatpack, and macOS has DMGs signed with entitlements. Each has its way of configuring and how it is expected to work, and debugging sandboxing issues is no fun.
I made an application bundler specifically for Julia's MSIX, Snap, and DMG applications, which allows the use of the underlying configuration files when configuring the sandbox via a simple recipe system. Unlikely one would change languages, but perhaps some inspiration can be taken from my project:
Yes, GoReleaser served as an inspiration to get started with the tool. The guide does mention this connection. I can certainly add one more entry to the FAQ to make it easier to find.
Regarding multi-language support, it’s available since day 1. Recently it became better https://andresalmiray.com/multi-language-support-in-jrelease...
I think jRelease was based on some of GoReleaser's ideas.
GoReleaser just recently started adding support for more languages.
[1] https://jreleaser.org/guide/latest/index.html#_acknowledgmen...
I also configured the announcement feature, so now I can share each release on my discord server and hopefully soon on LinkedIn.
The documentation of JReleaser is quite comprehensive, however does not fully cover "howto" steps regarding auth for each provider. Which in my case translated to initial cycle of try-and-error with my GitHub actions.
Support for explicit Python ecosystem tools and services (pypi, .whl files, etc) is forthcoming.