JReleaser: quick and effortless way to release your project

saikatsg | 85 points

I just built a library on jReleaser!

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.)

nja | 6 hours ago

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.

gunnarmorling | 10 hours ago

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.
(Or they can run go.sh/go.bat which essentially does the same thing.)

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.

whartung | 10 hours ago

Is it somehow related to GoReleaser? I saw GoReleaser supports multiple languages now as well

brunoluiz | 12 hours ago

Is there a doc for Python apps?

buremba | 9 hours ago

This doesn’t seem to address building installers, unfortunately.

layer8 | 11 hours ago