Publish CLI to Maven Central

[egorikftp]

• closes: Publish CLI to maven #683

blocked by GradleUp/nmcp#210

[coderabbitai]

Walkthrough

The PR introduces Maven Central publishing capability for the CLI artifact. It adds a GitHub Actions workflow step to publish non-snapshot releases to Maven Central Repository via the OSSRH portal. The build configuration is updated to include Maven publishing, GPG signing, and the nmcp (Nyx Maven Central Publisher) plugin. Dependencies on shadow, spotless, and updated JetBrains plugins are added to the version catalog. The CLI build configuration is enhanced with Maven publication metadata, signing configuration, and artifact packaging adjustments (sourcesJar, javadocJar, and shadowJar classifier changes). A plugin alias rename from buildConfig to buildconfig is applied across multiple files.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

• Credentials and secrets handling: Verify PGP key usage pattern in build files (useInMemoryPgpKeys) and environment variable sourcing matches GitHub Actions workflow expectations
• Maven publication configuration: Review tools/cli/build.gradle.kts for correct POM metadata structure, publication naming ("shadow"), and artifact setup (shadow component, sourcesJar, javadocJar)
• nmcp aggregation block: Ensure centralPortal subsection configuration and publishingType setting are compatible with OSSRH publisher expectations
• Plugin version compatibility: Verify nmcp version 1.2.1, buildconfig version 5.7.1, shadow version 9.2.2, and spotless version 8.0.0 are compatible with the project
• Artifact naming and classifier changes: Validate that shadowJar archiveClassifier empty string change and buildWithR8 task jar path updates align correctly with downstream publication

Possibly related PRs

• Valkyrie#690: Extends and modifies the same CLI release workflow and CLI build scripts with Maven Central publishing, signing, and packaging configuration changes.

Suggested labels

housekeeping

Suggested reviewers

• Goooler
• vkatz

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	❓ Inconclusive	Changes to plugin versions and library updates (buildconfig, nmcp, shadow, spotless, jetbrains-*) appear necessary for Maven Central publishing infrastructure but lack explicit documentation linking them to the core publishing objective.	Clarify whether all dependency version updates and plugin changes are necessary prerequisites for Maven Central publishing or if some represent scope creep.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Publish CLI to Maven Central' directly describes the main change: adding functionality to publish the CLI artifact to Maven Central repository.
Description check	✅ Passed	The description references linked issue #683 which relates to publishing the CLI to Maven, and notes a blocking dependency, both relevant to the changeset.
Linked Issues check	✅ Passed	The PR implements Maven Central publishing for the CLI through workflow changes, Gradle build configuration, and signing setup, fulfilling the core objective of issue #683.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch task/publish-cli-to-maven

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9cd12f3 and f7f7f2f.

📒 Files selected for processing (5)

• .github/workflows/cli-release.yml (1 hunks)
• build.gradle.kts (2 hunks)
• gradle/libs.versions.toml (1 hunks)
• tools/cli/build.gradle.kts (4 hunks)
• tools/gradle-plugin/build.gradle.kts (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-10-21T20:55:27.073Z

Learnt from: egorikftp
Repo: ComposeGears/Valkyrie PR: 651
File: tools/idea-plugin/build.gradle.kts:147-175
Timestamp: 2025-10-21T20:55:27.073Z
Learning: In Gradle Kotlin DSL (.gradle.kts) scripts, the types `org.gradle.api.artifacts.ArtifactCollection` and `org.gradle.api.artifacts.component.ModuleComponentIdentifier` are implicitly available and do not require explicit import statements.

Applied to files:

• tools/gradle-plugin/build.gradle.kts
• gradle/libs.versions.toml

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build (ubuntu-latest)

🔇 Additional comments (11)

tools/gradle-plugin/build.gradle.kts (1)

11-11: Plugin alias rename aligns with version catalog update.

The change from buildConfig to buildconfig is consistent across the project (build.gradle.kts, tools/cli/build.gradle.kts) and matches the updated plugin declaration in gradle/libs.versions.toml line 51.

build.gradle.kts (3)

18-18: Plugin alias rename is consistent.

Updated alias reference aligns with gradle/libs.versions.toml and other files in the PR.

---

21-21: nmcp plugin added for Maven Central publishing.

The plugin is properly declared and will be used by the nmcpAggregation configuration below.

---

92-100: Verify nmcp API: method name suggests potential project isolation implications.

The method publishAllProjectsProbablyBreakingProjectIsolation() has an intentionally cautionary name. Confirm that:

1. This method exists in nmcp 1.2.1
2. Project isolation concerns documented in the name are understood and acceptable
3. This is the intended approach to publish all maven-publish-enabled projects to Maven Central

To verify the nmcp plugin API, you can:

1. Check the nmcp documentation or official Gradle plugin portal
2. Run ./gradlew help --task publishAggregationToCentralPortal to see if the task is recognized
3. Review the nmcp 1.2.1 release notes for any breaking changes or API details

gradle/libs.versions.toml (2)

51-51: Plugin alias renamed consistently.

Change aligns with other Gradle scripts in the project.

---

62-64: I need to verify the remaining two dependencies before concluding the verification. Let me search for the shadow and spotless gradle plugins.

Let me search for the actual file structure to verify the format:

Verify nmcp aggregation plugin version availability.

Shadow 9.2.2 (created September 26, 2025) and spotless 8.0.0 (created September 24, 2025) are current latest versions, and spotless 8.0.0 is reported as the latest non-vulnerable version. The nmcp project documentation references version 1.2.0 for com.gradleup.nmcp.aggregation, but Maven Central shows only 1.0.0-rc.0 available for the aggregation plugin. Version 1.2.1 specified in the review was not found in public repositories and may be unavailable or from a pre-release channel.

tools/cli/build.gradle.kts (5)

3-3: Plugin and publication metadata setup looks solid.

• maven-publish and signing plugins properly declared
• withSourcesJar() and withJavadocJar() correctly configured for Maven Central requirements
• buildconfig alias updated consistently

Also applies to: 6-7, 11-14

---

25-27: Shadow artifact configuration is correct.

Setting addShadowVariantIntoJavaComponent = false prevents the shadow variant from being published as a separate artifact alongside the standard publication. The empty archiveClassifier = "" on line 51 ensures the shadow JAR becomes the primary artifact with the expected name pattern.

Also applies to: 50-51

---

115-155: Maven publication configuration is well-formed.

The "shadow" publication includes:

• Proper coordinates (groupId, artifactId, version)
• All required artifacts (shadow component + sourcesJar + javadocJar)
• Comprehensive POM metadata (name, description, licenses, SCM, developers)
• Proper URL and scoping

This aligns with Maven Central publication requirements.

---

157-165: Signing configuration is properly scoped and environment-aware.

The signing block:

• Conditionally activates only when both PGP_KEY and PGP_PASS environment variables are set
• Uses in-memory PGP keys via useInMemoryPgpKeys()
• The pipe-to-newline replacement (replace("|", "\n")) is standard for handling multiline secrets in GitHub Actions
• Correctly signs the "shadow" publication only

This approach is sound, but depends on the earlier fix to the GitHub workflow (line 72: PGP_PASS secret name correction).

Confirm that the PGP key format exported from your signing certificate uses | as a placeholder for newlines (or adjust the replacement character if your key export format differs).

---

124-125: I'll verify the assumption by examining the build file and searching for task definitions, since the Gradle daemon is unavailable in the sandbox environment.

Now let me examine the build file directly to verify the context:Based on my verification of official Gradle documentation and multiple sources, the withJavadocJar() method adds a task named javadocJar, and withSourcesJar() adds a task named sourcesJar. These tasks are registered as documentation variants on the java component, and the official Gradle documentation shows the exact pattern you're using: artifact(tasks["sourcesJar"]) to reference these auto-created tasks.

If the project already has a task named javadocJar then no task is created, but this is a safeguard rather than an error condition.

The assumption in the review comment is sound—the tasks will be available when the methods are called. The reference pattern tasks["sourcesJar"] and tasks["javadocJar"] on lines 124-125 is the standard and recommended approach for this use case.

The review comment concern is unfounded; no action required.

[Goooler]

I don't think you really need to publish the CLI first, see https://gradleup.com/shadow/publishing/#publishing-the-shadowed-gradle-plugins

[egorikftp]

I don't think you really need to publish the CLI first, see https://gradleup.com/shadow/publishing/#publishing-the-shadowed-gradle-plugins

Do you mean, that we can just publish shadow gradle plugin?

[Goooler]

Yeah.