5 ms·

JReleaser: quick and effortless way to release your project

131 points by saikatsg 2y ago

brunoluiz 2y ago
Is it somehow related to GoReleaser? I saw GoReleaser supports multiple languages now as well
- kbd 2y ago
  Had the same question, surprised it's not addressed in the faq.
  - aalmiray 2y ago
    JReleaser author here. 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-jreleaser/ https://andresalmiray.com/multi-language-support-in-jrelease...
- ashishb 2y ago
  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 2y ago
  GoReleaser author here. I think jRelease was based on some of GoReleaser's ideas. GoReleaser just recently started adding support for more languages.
- loginatnine 2y ago
  It's inspired by it. It's mentioned here[1]. [1] https://jreleaser.org/guide/latest/index.html#_acknowledgments https://jreleaser.org/guide/latest/index.html#_acknowledgmen...
layer8 2y ago
This doesn’t seem to address building installers, unfortunately.
- whartung 2y ago
  It creates MacOS packages, Windows MSI, and Linux bundles. Those are all "installers", right?
  - layer8 2y ago
    My apologies, I couldn’t find this in the documentation. Can you give me a link?
    - smarx007 2y ago
      https://jreleaser.org/guide/latest/reference/assemble/deb.html https://jreleaser.org/guide/latest/reference/assemble/deb.ht...
      - deleted 2y ago
        [deleted]
- aalmiray 2y ago
  It does. This is one of the initial reasons to create such tool. At the moment you can assemble native installers with jpackage (project must be Java based) https://jreleaser.org/guide/latest/reference/assemble/jpackage.html https://jreleaser.org/guide/latest/reference/assemble/jpacka... or create a .deb file (does not bundle a Java runtime, project does not have to be Java based) https://jreleaser.org/guide/latest/reference/assemble/deb.html https://jreleaser.org/guide/latest/reference/assemble/deb.ht...
- Noumenon72 2y ago
  Thank you for posting this because I had the same question and installers weren't mentioned when I asked ChatGPT what "releasing" is.
whartung 2y 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.
- koito17 2y ago
  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.
  - diggan 2y ago
    > 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*
gunnarmorling 2y 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 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.
buremba 2y ago
Is there a doc for Python apps?
- aalmiray 2y ago
  Technically it already works as long as your app is published to GH releases and/or the currently supported package managers. Support for explicit Python ecosystem tools and services (pypi, .whl files, etc) is forthcoming.
nja 2y ago
I just built a library on jReleaser! https://github.com/NJAldwin/maven-central-test 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 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.)
pitah1 2y ago
This looks really cool. I'm surprised I didn't find this before when I was searching for something like this. I've been using jpackage[1] for a while now but this seems like it would be easier for me to manage using JReleaser given there is support via Gradle. 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/jpackage.html https://docs.oracle.com/en/java/javase/22/docs/specs/man/jpa...
- aalmiray 2y ago
  Given that JReleaser relies on jpackage to create native installers, yes, you must run it on the target platform. Luckily it’s not that complicated to do on GitHub Actions. JReleaser offers plenty of examples for different setups, here’s how to do it for jpackage https://jreleaser.org/guide/latest/examples/java/jpackage.html https://jreleaser.org/guide/latest/examples/java/jpackage.ht...
morisil 2y ago
I am happy with JReleaser, I just started migrating all my libraries from publishing through io.github.gradle-nexus.publish-plugin to publishing with jreleaser, which became necessary after migrating my sonatype account to the new maven central scheme. https://github.com/xemantic/ https://github.com/xemantic/ 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.

131 points by saikatsg 2y ago

brunoluiz 2y ago

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

kbd 2y ago
Had the same question, surprised it's not addressed in the faq.
- aalmiray 2y ago
  JReleaser author here. 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-jreleaser/ https://andresalmiray.com/multi-language-support-in-jrelease...
ashishb 2y ago
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 2y ago
GoReleaser author here. I think jRelease was based on some of GoReleaser's ideas. GoReleaser just recently started adding support for more languages.
loginatnine 2y ago
It's inspired by it. It's mentioned here[1]. [1] https://jreleaser.org/guide/latest/index.html#_acknowledgments https://jreleaser.org/guide/latest/index.html#_acknowledgmen...

layer8 2y ago

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

whartung 2y ago
It creates MacOS packages, Windows MSI, and Linux bundles. Those are all "installers", right?
- layer8 2y ago
  My apologies, I couldn’t find this in the documentation. Can you give me a link?
  - smarx007 2y ago
    https://jreleaser.org/guide/latest/reference/assemble/deb.html https://jreleaser.org/guide/latest/reference/assemble/deb.ht...
    - deleted 2y ago
      [deleted]
aalmiray 2y ago
It does. This is one of the initial reasons to create such tool. At the moment you can assemble native installers with jpackage (project must be Java based) https://jreleaser.org/guide/latest/reference/assemble/jpackage.html https://jreleaser.org/guide/latest/reference/assemble/jpacka... or create a .deb file (does not bundle a Java runtime, project does not have to be Java based) https://jreleaser.org/guide/latest/reference/assemble/deb.html https://jreleaser.org/guide/latest/reference/assemble/deb.ht...
Noumenon72 2y ago
Thank you for posting this because I had the same question and installers weren't mentioned when I asked ChatGPT what "releasing" is.

whartung 2y 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.

koito17 2y ago
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.
- diggan 2y ago
  > 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*

gunnarmorling 2y 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 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.

buremba 2y ago

Is there a doc for Python apps?

aalmiray 2y ago
Technically it already works as long as your app is published to GH releases and/or the currently supported package managers. Support for explicit Python ecosystem tools and services (pypi, .whl files, etc) is forthcoming.

nja 2y ago

I just built a library on jReleaser! https://github.com/NJAldwin/maven-central-test 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 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.)

pitah1 2y ago

This looks really cool. I'm surprised I didn't find this before when I was searching for something like this. I've been using jpackage[1] for a while now but this seems like it would be easier for me to manage using JReleaser given there is support via Gradle. 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/jpackage.html https://docs.oracle.com/en/java/javase/22/docs/specs/man/jpa...

aalmiray 2y ago
Given that JReleaser relies on jpackage to create native installers, yes, you must run it on the target platform. Luckily it’s not that complicated to do on GitHub Actions. JReleaser offers plenty of examples for different setups, here’s how to do it for jpackage https://jreleaser.org/guide/latest/examples/java/jpackage.html https://jreleaser.org/guide/latest/examples/java/jpackage.ht...

morisil 2y ago

I am happy with JReleaser, I just started migrating all my libraries from publishing through io.github.gradle-nexus.publish-plugin to publishing with jreleaser, which became necessary after migrating my sonatype account to the new maven central scheme. https://github.com/xemantic/ https://github.com/xemantic/ 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.