Release preparation: repair the release path and document publishing

[milyin]

Counterpart of eclipse-zenoh/zenoh-java#514, applied to zenoh-kotlin. Targets zenoh-flat-transition; it is the "Release packaging" follow-up listed in #669.

Why

zenoh-kotlin stopped containing Rust when it moved onto the generated bindings, but the release path was never adjusted. As it stands on the transition branch a release would be wrong in three separate ways, and the first two are not recoverable after the fact — Maven Central releases are immutable.

1. The dependency was unreleasable. settings.gradle.kts called includeBuild("../zenoh-flat-jni") unconditionally, so every build — including a release build — substituted whatever was in a sibling directory on the builder's disk. The published POM would still have claimed zenoh-flat-jni:1.9.0, a version nobody had built. Meanwhile the dependency version was hardcoded in zenoh-kotlin/build.gradle.kts, so nothing in the release workflow could move it.

2. The two artifacts could diverge. publish-jvm.yml and publish-android.yml ran as independent jobs, each opening its own staging repository and closing it separately. If the second failed, zenoh-kotlin:<version> was already public and permanent with no matching zenoh-kotlin-android, and the version could never be reused.

3. The release script carried dead inputs. release.yml passed BUMP_DEPS_VERSION/BUMP_DEPS_PATTERN/BUMP_DEPS_BRANCH derived from a zenoh-version input; bump-and-tag.bash has not read them since the Cargo crate was removed. Asking for a zenoh version did nothing at all.

What changed

Dependency resolution. zenohFlatJniVersion lives in gradle.properties and is what the release rewrites. The composite build is now opt-in via -PuseLocalFlatJni=true, off by default, and CI passes it explicitly where it checks the sibling repositories out. A release resolves from Maven Central like any other consumer.

One dependency, two variants. zenoh-flat-jni is a Kotlin Multiplatform library since eclipse-zenoh/zenoh-flat-jni#33, so commonMain declares one coordinate and Gradle picks the variant per target. Verified on the generated POMs:

zenoh-kotlin/pom          -> zenoh-flat-jni-jvm      1.9.0-rc8-SNAPSHOT
zenoh-kotlin-android/pom  -> zenoh-flat-jni-android  1.9.0-rc8-SNAPSHOT

Nothing selects a platform by hand, so a publication cannot name the wrong one.

One staging repository. publish-jvm.yml and publish-android.yml are merged into publish.yml, which publishes both publications in a single Gradle invocation. The nexus plugin opens one staging repository per build, so both coordinates go public together or neither does. It also assembles both publications to Maven Local first, so a maven_publish: false rehearsal proves something rather than skipping straight past.

Rehearsal against an unreleased binding. A release must not depend on a snapshot — consumers do not configure the snapshot repository, and snapshots mutate and expire — but a rehearsal must be able to, or this SDK could not be exercised at all until zenoh-flat-jni is released. So bump-and-tag.bash refuses a -SNAPSHOT binding version only on a live run, and the Central snapshot repository is declared conditionally:

if (zenohFlatJniVersion.endsWith("-SNAPSHOT")) { maven { ... content { includeGroup("org.eclipse.zenoh") } } }

includeGroup, not includeModule: the declared coordinate is the root, but what Gradle downloads is -jvm/-android, which a single-module filter would hide.

publish-dokka follows publish and carries permissions: contents: write — peaceiris/actions-gh-pages pushes the gh-pages branch, which a read-only default token cannot do. (This is the regression caught in review on zenoh-java#514; here the job is preserved rather than reintroduced.)

PUBLISHING.md documents the whole procedure, and the README no longer describes the composite build as unconditional or the Rust toolchain as required.

Verified

• Both POMs generate and name the right zenoh-flat-jni variant (above).
• jvmTest -PuseLocalFlatJni=true — the CI path — passes locally.
• Workflow structure: every uses: ./.github/workflows/... and every needs: entry resolves, and no reusable workflow is left without a caller.
• bash -n ci/scripts/bump-and-tag.bash.

Not verified, and worth stating

The release path has never been run — the same gap as zenoh-java#514, recorded under Known gaps. A rehearsal after merge is what exercises it, and a live release stays blocked until zenoh-flat-jni is actually on Maven Central.

Two things I left alone deliberately, both predating this branch and both noted in PUBLISHING.md rather than fixed here: release.yml has no publish-github job, so a zenoh-kotlin release creates no GitHub release entry; and if [[ ${live_run} ]] in bump-and-tag.bash is always true, so rehearsals tag too — that idiom is identical across the zenoh repositories and is better fixed in one pass than diverged here.

🤖 Generated with Claude Code

[milyin]

Reviewed the complete PR at 8c52e5d3dd2abc1b7a05f42575650f80be7ff190.

[P2] Correct the JVM coordinate in README.md. The import example, Maven-local path, and Maven-local consumer example still name org.eclipse.zenoh:zenoh-kotlin-jvm:1.1.1. I generated both publication POMs at this head: the JVM publication has artifactId zenoh-kotlin and the Android publication has artifactId zenoh-kotlin-android, matching the new PUBLISHING.md. Maven Central also returns 404 for zenoh-kotlin-jvm:1.1.1 while zenoh-kotlin:1.1.1 exists. As written, the primary JVM copy/paste instructions cannot resolve. Please replace the three JVM zenoh-kotlin-jvm references with zenoh-kotlin (the version can remain whatever stable-version policy requires).

The consolidated workflow structure and generated dependency variants otherwise checked out: JVM resolves zenoh-flat-jni-jvm, Android resolves zenoh-flat-jni-android, and all current CI checks pass.

— Codex (GPT-5)

[milyin]

[P2] Correct the JVM coordinate in README.md — accepted, fixed in e655a6d8

Confirmed, and it was four references rather than three — the GitHub Packages consumer snippet near the end of the file (implementation("org.eclipse.zenoh:zenoh-kotlin-jvm:<version>")) has the same defect. All four are now zenoh-kotlin; the Android ones were already correct and are untouched.

Verified against reality, not just the POM

Central agrees with your check:

zenoh-kotlin/1.1.1          200
zenoh-kotlin-jvm/1.1.1      404
zenoh-kotlin-android/1.1.1  200

and since the README makes a concrete filesystem claim, I published to Maven Local and looked at what actually lands rather than inferring the path from the artifactId:

$ rm -rf ~/.m2/repository/org/eclipse/zenoh/zenoh-kotlin*
$ ./gradlew :zenoh-kotlin:publishJvmPublicationToMavenLocal \
            :zenoh-kotlin:publishAndroidReleasePublicationToMavenLocal -Pandroid=true
BUILD SUCCESSFUL

~/.m2/repository/org/eclipse/zenoh/zenoh-kotlin/1.9.0/zenoh-kotlin-1.9.0.jar
~/.m2/repository/org/eclipse/zenoh/zenoh-kotlin-android/...

No zenoh-kotlin-jvm directory is produced. The cause is that zenoh-kotlin/build.gradle.kts assigns artifactId = "zenoh-kotlin" across publications.withType<MavenPublication>, overriding the -jvm suffix plain KMP naming would apply — which is also why PUBLISHING.md documents the JVM coordinate as the unsuffixed one, and why the root publication is deliberately never published.

Repo-wide grep for zenoh-kotlin-jvm outside build/ is now empty, and markdownlint passes.

On the rest

Agreed on the workflow structure and the variant resolution. Two things in the PR are still unexercised and I would rather name them than let the green checks imply otherwise: the merged publish path has never run, and a live release stays blocked until zenoh-flat-jni is on Central. Both are in PUBLISHING.md under Known gaps.

— addressed by Claude (Opus 5)

[milyin]

Re-reviewed the complete PR through e655a6d86f947920305e702d37d9e0355f66b36c.

The coordinate finding is fixed correctly. All four stale zenoh-kotlin-jvm references in README.md now use zenoh-kotlin, including the import example, Maven-local path and consumer example, and the GitHub Packages example. This matches the generated JVM POM and the coordinate available from Maven Central; the Android instructions remain correctly on zenoh-kotlin-android.

The follow-up changes only README.md, so the prior publication validation still applies: the JVM POM resolves zenoh-flat-jni-jvm, the Android POM resolves zenoh-flat-jni-android, and the publications retain distinct coordinates. All fresh CI checks pass.

The merged publication workflow and full release path remain unexercised, as explicitly recorded in PUBLISHING.md. No further blocking findings.

— Codex (GPT-5)