JReleaser: quick and effortless way to release your project
17 comments
·January 21, 2025whartung
When I released my last Java project, I came out with a MacOS DMG, a Windows EXE installer, a Windows MSI installer, and a Fat Jar for Linux.
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.
koito17
Distributing a single uberjar, whenever possible, is generally a good idea IMO. One major reason I like the JVM as a platform is that I don't need to mess with containers or native images. To reduce burden of deployment, native images are out of the question. Thus the choices are "force user to have Java runtime installed" or "force user to have container runtime installed". Double-clicking a JAR file (or running "java -jar ...") tends to be easier than debugging Mac / Windows quirks with Docker.
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.
whartung
I absolutely agree on the JVM platform, an uber jar file is really quite easy to use and deploy.
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).
diggan
> Distributing a single uberjar, whenever possible, is generally a good idea IMO.
Yeah, seems to work for games well enough. Ship uberjar + small wrapper shellscript for Linux/macOS, .bat for Windows. Should work everywhere*
invalidname
Did you look at https://www.jdeploy.com/ ?
brunoluiz
Is it somehow related to GoReleaser? I saw GoReleaser supports multiple languages now as well
loginatnine
It's inspired by it. It's mentioned here[1].
[1] https://jreleaser.org/guide/latest/index.html#_acknowledgmen...
ashishb
I love go-releaser. I believe it is a great choice for Go-based projects. I use it for multiple side-projects of mine (that are written in Go).
caarlos0
GoReleaser author here.
I think jRelease was based on some of GoReleaser's ideas.
GoReleaser just recently started adding support for more languages.
kbd
Had the same question, surprised it's not addressed in the faq.
buremba
Is there a doc for Python apps?
Very nice to see JReleaser here on HN! I'm very happy with it, using it for publishing releases of kcctl (a command line client for Kafka Connect written in Java, compiled and published as native binaries for Linux/MacOS/Win via GraalVM). Here's the config, in case folks are looking for an example: https://github.com/kcctl/kcctl/blob/main/pom.xml#L430-L530. Releases are triggered by running a parameterized workflow (taking the version to be released) on GitHub Actions.
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.