fix: consolidate publishing onto pluginMaven to fix release signing collision#296
Conversation
…igning The 2.10.0 release failed at `signPluginMavenPublication` with an implicit task-dependency error: the hand-rolled `release` publication and the plugin-publish-managed `pluginMaven` publication both reference the same physical jars, so `signReleasePublication` and `signPluginMavenPublication` each wrote the same `*.asc` files. `publishReleasePublicationToMavenRepository` then consumed an `.asc` produced by `signPluginMavenPublication` without a declared dependency, which Gradle rejects. Drop the separate `release` publication and reuse plugin-publish's `pluginMaven` for both Maven Central and the Plugin Portal: a single publication means a single set of artifacts and a single signing task per artifact, so there is no `.asc` collision. The Maven Central coordinate stays `com.deploygate:gradle` (artifactId override), and the plugin marker keeps depending on `com.deploygate:gradle`. - build.gradle: configure `pluginMaven` (artifactId + pom) instead of a separate `release` publication; drop the explicit `sign` call (plugin-publish already signs pluginMaven + marker); gate signing on the new `publishPluginMavenPublicationToMavenRepository` task. - release.sh: publish via `publishPluginMavenPublicationToMavenRepository`. Verified locally with a throwaway GPG key: a signing-required publish of both `pluginMaven` and the marker to a file repository succeeds with no implicit- dependency error and emits signed jar/sources/javadoc/module/pom (+ marker). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the publishing configuration in build.gradle to reuse the pluginMaven publication generated by the java-gradle-plugin instead of maintaining a separate hand-rolled publication. This avoids duplicate signing tasks and conflicting signature files. The publishing task name is updated accordingly in both build.gradle and release.sh. Feedback suggests improving the robustness of the task graph check in build.gradle by checking task names dynamically rather than using hasTask, which can fail depending on how the task path is specified.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
Pull request overview
This PR aims to fix a Gradle publishing/signing collision during release by consolidating Maven Central publishing onto the existing pluginMaven publication (managed by com.gradle.plugin-publish), removing the separate hand-rolled release publication that caused .asc output conflicts.
Changes:
- Update
release.shto publish to Maven Central viapublishPluginMavenPublicationToMavenRepositoryinstead of the removedreleasepublication task. - Reconfigure
build.gradleto customize the existingpluginMavenpublication (notably the Maven Central artifactId) instead of defining a second publication. - Adjust signing configuration to gate on the new publish task (but currently removes explicit signing of publications).
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| release.sh | Switches release publishing task to publishPluginMavenPublicationToMavenRepository. |
| build.gradle | Drops the custom release publication and reuses/configures pluginMaven; updates signing gating accordingly. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
`gradle.taskGraph.hasTask("publishPluginMavenPublicationToMavenRepository")`
compares against the task *path* (":publishPluginMavenPublicationToMavenRepository"),
so the bare-name argument never matched and `signing.required` was effectively
always false — signing only happened when a key was present, and a release run
with a missing key would silently publish unsigned artifacts (which Maven
Central then rejects).
Match by task name via `gradle.taskGraph.allTasks.any { it.name == ... }` so the
gate fails fast when a release runs without a signing key. Verified locally:
with a key the publish signs and succeeds; without a key the build now fails at
`signPluginMavenPublication` ("no configured signatory") instead of skipping.
Addresses review feedback from gemini-code-assist on PR #296.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@copilot Thanks for the review — the summary is accurate. One clarification: removing the explicit Verified locally with a real key: the |
|
Thanks again! |
Problem
The 2.10.0 release failed at
Task :signPluginMavenPublication:Root cause: the hand-rolled
releasepublication and the plugin-publish-managedpluginMavenpublication reference the same physical jars. With signing required,signReleasePublicationandsignPluginMavenPublicationboth write the same*.ascfiles, and the Central publish task consumes an.ascproduced by the other publication's sign task. (LocalpublishToMavenLocaldidn't catch this because signing wasSKIPPEDthere.)Nothing was published — Maven Central returns 404 for
com.deploygate:gradle:2.10.0, so the same version can be re-released after this fix.Fix
Drop the separate
releasepublication and reuse plugin-publish'spluginMavenfor both Maven Central and the Plugin Portal. One publication ⇒ one set of artifacts ⇒ one signing task per artifact ⇒ no.asccollision.pluginMaven(setartifactId = gradlefor back-compat + the pom) instead of a second publication; remove the explicitsigncall (plugin-publish already signspluginMaven+ marker); gate signing onpublishPluginMavenPublicationToMavenRepository.publishPluginMavenPublicationToMavenRepository.The marker still depends on
com.deploygate:gradle(verified), and the jar still ships bothdeploygate.propertiesandcom.deploygate.properties.Verification (local, throwaway GPG key)
A signing-required (
RELEASE_SCRIPT_TEST=true) publish ofpluginMaven+ the marker to afile://repo succeeds with no implicit-dependency error, emitting signedjar/sources/javadoc/module/pom(+.asc) forcom.deploygate:gradle:2.10.0and the signed marker pom.spotlessCheckandvalidatePluginspass.After merge
Re-point
git tag -f 2.10.0onto the new HEAD and force-push to re-trigger the release.🤖 Generated with Claude Code