jvm-release

Guides publishing Java and Kotlin artifacts to Maven Central through ordered release gates.

Updated Aug 13, 2026
One-click install
npx skills add https://github.com/ocx-sh/grimoire-lore --skill jvm-release-ocx-sh
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: jvm-release
Source: https://github.com/ocx-sh/grimoire-lore/tree/main/skills/jvm-release
Command: npx skills add https://github.com/ocx-sh/grimoire-lore --skill jvm-release-ocx-sh

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Publishing to Maven Central is irreversible once a deployment reaches PUBLISHED, and common mistakes like missing sources jars, incomplete POMs, skipped binary-compatibility checks, or jobs that stop at VALIDATED instead of PUBLISHED cost a version number every time. This Skill provides an ordered, gate-based runbook that catches every defect before the artifact leaves the machine. ## Core Features & Use Cases - Gate-ordered release runbook: Eight ordered steps covering namespace verification, tag-versus-version gating, binary-compatibility checks (japicmp, Kotlin ABI validator), the required per-file set, signing, and exit semantics, for both Gradle and Maven side by side. - Dead-path detection: Names the obsolete OSSRH endpoints, nexus-staging plugins, and OIDC assumptions that models propose from pre-2025 training data, with grep-based checks to find them in a repository. - Review-ready findings table: Sixteen merge-blocking MUST rows mapped to rule IDs (GRADLE-PUB, MVN-PUB, JAVA-API, KT-API) so a review reports findings with stable identifiers. - Use Case: A team cutting a Kotlin library release runs the runbook to verify the git tag matches gradle.properties, confirm apiCheck runs before the publish task, validate the generated POM contains url and scm blocks, and configure nmcp with AUTOMATIC publishing so a green CI job means the artifact is live on Central. ## Quick Start Use the jvm-release skill to review my Gradle release workflow and tell me whether a green job means the artifact is actually published to Maven Central.

Frequently Asked Questions about jvm-release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I publish a Java or Kotlin library to Maven Central?▼

Verify your namespace first, then gate the git tag against the declared version, run a binary-compatibility check, assemble the required per-file set including sources and javadoc jars, sign every publication, and upload with autoPublish and waitUntil set to published. Gradle uses nmcp or the vanniktech plugin; Maven uses central-publishing-maven-plugin 0.7.0 or above.

Why does my release job succeed but the artifact is not on Maven Central?▼

The default deployment stops at VALIDATED, which still requires a manual publish click and can fail asynchronously. Set autoPublish to true and waitUntil to published so the job's exit code means the deployment reached PUBLISHED.

Can I still publish through oss.sonatype.org or nexus-staging-maven-plugin?▼

No. OSSRH reached end of life on 2025-06-30, and the nexus-staging plugins are dead paths. The current targets are the Central Portal with nmcp or the vanniktech plugin for Gradle, and central-publishing-maven-plugin for Maven.

What files does Maven Central require for each published artifact?▼

Each artifact needs the main jar, a matching sources jar, a javadoc jar, a complete POM with name, description, url, licenses, developers, and a full scm block, plus .asc, .md5, and .sha1 files per deployed file. Central rejects the whole deployment if any single element is missing.

Does Maven Central support OIDC trusted publishing like PyPI?▼

No. As of the documented Portal guide and Publisher API, Central has no OIDC path. Use a Portal token stored in CI secrets, and do not write a tokenless release job without a primary source confirming support.

How do I check binary compatibility before a Java or Kotlin release?▼

For Java, bind japicmp to check or verify and make every publish task depend on it, with accepted breaks in a reviewed allowlist. For Kotlin, run exactly one ABI gate: standalone binary-compatibility-validator or in-KGP abiValidation, never both.