aalmiray

JReleaser offers plenty of examples for Java and non-Java projects. All of them have explicit setup for building on GitHub Actions. Some repos (non platform specific or cross-platform) can be fully built and released on a local environment as well, not just CI https://jreleaser.org/guide/latest/examples/index.html

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

This burden is what prompted me to create JReleaser in the first place as I also wanted to release a JavaFX application without instructing people to clone a repository and build the app themselves.

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.

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/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.ht...

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.

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

To my knowledge there have been no official efforts to support Clojure so far. Griffon 2.x requires the use of specific class types (Controller, Model, View, etc) plus the use of annotation processors make life easier (although not strictly required). These could make your Clojure code look less idiomatic and more Java-ish.

However there was an experimental branch of 2.x with Frege support, which means Clojure is certainly doable.

There may be few tweets but development still continues, on the road to version 3.0.0. The source repository continues to have activity.

Changes include: - support of Java's modular system (JPMS) which requires elimination of split packages, besides providing module descriptors. - take advantage of lambdas where possible.

Latest release is 2.15.1 (stable). Current development (3.x) is still in flux with big internal changes hence the breakages. I decided to post the changes to let people know what's coming even if that meant breaking builds from time to time.