JReleaser is an Apache-2.0 release automation tool for Java and non-Java projects that creates releases and publishes artifacts to multiple package managers, aimed at maintainers who want their build pipeline to run the release instead of doing it by hand.

What it is

JReleaser is a release automation tool written in Java and licensed under Apache-2.0. It lives in the JVM ecosystem, where it integrates with the build tools maintainers already use: Maven, Gradle, and Ant. Its stated goal is to simplify creating releases and publishing artifacts to multiple package managers while providing customizable options. The project is not limited to Java, however; the README and topic list name Go, Rust, Elixir, and C# among the languages it supports, and the registry lists csharp, rust, and elixir alongside java, maven, gradle, and ant as topics. Version 1.26.0 is the current documented release, and the tool is distributed through both Maven Central and the Gradle Plugin Portal.

The concrete problem it solves is the last mile of a software release. Cutting a version and pushing the resulting artifacts to several package managers is repetitive, error-prone, and usually handled by hand-written scripts or manual upload steps that differ from one project to the next. JReleaser replaces that ad-hoc release process with a single configurable tool that can run on a development machine or inside a CI/CD pipeline. A maintainer declares the release once and lets the tool handle creating the release and distributing artifacts, rather than orchestrating each package manager separately.

Key capabilities

• Automates releases for Java projects and for non-Java projects including Go, Rust, Elixir, and C#.
• Publishes artifacts to multiple package managers from a single release definition.
• Ships as a Gradle plugin published under the plugin ID org.jreleaser on the Gradle Plugin Portal.
• Publishes Maven artifacts; org.jreleaser:jreleaser-model-api is available on Maven Central at version 1.26.0.
• Runs both on a development environment and on CI/CD systems.
• Distributed as the Docker image jreleaser-slim for container-based execution.
• Provides a command-line interface, listed as the cli topic.
• Release artifacts carry verifiable supply-chain signals: SLSA Level 3, an OpenSSF Best Practices badge, an OpenSSF Scorecard, and a Reproducible Central artifact badge.

Who uses it and how

• JVM maintainers using Maven, Gradle, or Ant who want the build to publish releases without custom scripting per project.
• Maintainers of non-Java projects in Go, Rust, Elixir, or C# who want the same release automation that JVM projects get.
• Teams running CI/CD pipelines, which the README names as a first-class place to install and run JReleaser.
• Container-oriented builds that prefer the jreleaser-slim image over a locally installed binary.
• Projects that need to distribute one release to several package managers at once instead of publishing to each separately.

Getting started

Install JReleaser on a development environment or on a CI/CD system, following the install guide linked from the README at https://jreleaser.org/guide/latest/install.html; versioned documentation for 1.26.0 is published at https://jreleaser.org/guide/latest. A jreleaser-slim Docker image is also published for container-based runs.

How it compares

No list of paid products that this project replaces was provided in the facts, and the facts name no direct alternative release automation tools. JReleaser therefore stands alone in this registry, with Maven, Gradle, and Ant appearing only as ecosystems it integrates with rather than as competing products.

When to use it — and when not to

Choose JReleaser if a project already builds with Maven, Gradle, or Ant and needs releases published to several package managers without hand-written glue, or if a non-Java project wants comparable automation. Be aware that the README excerpt does not document runtime dependencies such as a database or external services, so operational requirements must be confirmed from the linked guide before committing. The README is also thin on inline installation detail, the repository carries 127 open issues, and a self-hoster should expect to read the external documentation rather than the repository front page.