Publish Gradle plugin to Plugin Portal, keep Central listing clean

[kirich1409]

Problem

On Maven Central the Gradle plugin showed up as multiple components, not a single clean library release:

• dev.androidbroadcast.featured:featured-gradle-plugin — the real impl jar (good)
• dev.androidbroadcast.featured:dev.androidbroadcast.featured.gradle.plugin — plugin marker
• dev.androidbroadcast.featured.application:dev.androidbroadcast.featured.application.gradle.plugin — second marker, under its own groupId

The marker artifacts are auto-generated by java-gradle-plugin (one per plugin id). Their coordinates are fixed by Gradle (<id>:<id>.gradle.plugin) and cannot be renamed. On Maven Central they polluted the listing and split the release across two groupId namespaces.

Solution

Publish the plugin (and its markers) to the Gradle Plugin Portal — the conventional resolution channel for plugins { id(...) version "..." } — and keep Maven Central carrying only the clean featured-gradle-plugin impl jar (+ sources/javadoc/pom).

• Apply com.gradle.plugin-publish 2.1.1; add website/vcsUrl + per-plugin displayName/description/tags.
• Disable the marker→Central publish tasks so the two *.gradle.plugin stubs no longer reach Central; the Portal hosts them via publishPlugins.

Why not the "canonical" Vanniktech platform switch

Vanniktech's GradlePublishPlugin platform is auto-selected when com.gradle.plugin-publish is applied, but in 0.36.0 its configure() is a no-op — it does not scope what goes to Central. Gradle's maven-publish still generates a publish<Pub>PublicationToMavenCentralRepository task for every publication, markers included. The Central bundle is built by walking the staging dir (MavenCentralBuildService), so a Central task with enabled = false never writes its files and the marker is absent from the bundle. Disabling those two tasks is therefore the correct, version-robust mechanism on 0.36 — not a workaround around a working platform.

Verification

• :featured-gradle-plugin:test — 266/266 pass
• publishToMavenLocal — BUILD SUCCESSFUL; impl carries jar + sources + javadoc + pom + module
• Central task predicate verified: exactly the two …PluginMarkerMavenPublicationToMavenCentralRepository tasks are disabled; publishPluginMavenPublicationToMavenCentralRepository (impl) stays enabled
• publishPlugins (Portal) task present
• spotlessCheck — pass

No network publish was performed.

⚠️ Required follow-up before the next release

Removing markers from Central means plugins { id(...) } now resolves only via the Gradle Plugin Portal. Before the next release the maintainer must:

1. Register both plugin ids on the Gradle Plugin Portal.
2. Add a :featured-gradle-plugin:publishPlugins step to the release workflow, gated on Portal credentials gradle.publish.key / gradle.publish.secret (GRADLE_PUBLISH_KEY / GRADLE_PUBLISH_SECRET).

Side benefit: the README plugins {} snippet now works out of the box via the default gradlePluginPortal(), whereas before it silently required mavenCentral() in pluginManagement.

🤖 Generated with Claude Code

[qodo-code-review]

Review Summary by Qodo

Publish Gradle plugin to Plugin Portal, keep Central listing clean

✨ Enhancement

Walkthroughs

Description

• Publish Gradle plugin to Plugin Portal via com.gradle.plugin-publish
• Disable marker artifact publishing to Maven Central for cleaner listing
• Add plugin metadata: displayName, description, tags, website, vcsUrl
• Marker artifacts now resolve exclusively via Gradle Plugin Portal

Diagram

flowchart LR
  A["java-gradle-plugin<br/>marker artifacts"] -->|"publishPlugins"| B["Gradle Plugin Portal"]
  C["featured-gradle-plugin<br/>impl jar"] -->|"enabled=true"| D["Maven Central"]
  A -->|"disabled tasks"| E["❌ Maven Central<br/>marker stubs"]
  B -->|"clean listing"| D

Loading

File Changes

1. featured-gradle-plugin/build.gradle.kts ✨ Enhancement +32/-0

Configure plugin publishing and disable marker artifacts

• Applied com.gradle.plugin-publish plugin for Portal publishing
• Added plugin metadata: displayName, description, tags for both plugins
• Configured website and vcsUrl in gradlePlugin block
• Disabled marker→Central tasks via PublishToMavenRepository predicate matching
 PluginMarkerMavenPublicationToMavenCentralRepository
• Added detailed comments explaining marker artifact routing strategy

featured-gradle-plugin/build.gradle.kts

---

2. gradle/libs.versions.toml Dependencies +2/-0

Add Gradle plugin-publish dependency

• Added pluginPublish = "2.1.1" version reference
• Registered com.gradle.plugin-publish plugin alias

gradle/libs.versions.toml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

1. Portal publish not automated 🐞 Bug ☼ Reliability

Description

featured-gradle-plugin disables publishing plugin-marker artifacts to Maven Central, but the
release workflow still only runs publishToMavenCentral. This will ship a release where the plugin
ids are not published to the Gradle Plugin Portal (no publishPlugins run), so consumers using the
plugins {} DSL won’t be able to resolve the plugin.

Code

featured-gradle-plugin/build.gradle.kts[R88-92]

Evidence

The build explicitly disables Maven Central publishing for plugin marker publications and documents
that markers should instead be uploaded via publishPlugins to the Gradle Plugin Portal; the
release workflow currently runs only publishToMavenCentral, so no Portal upload occurs.

featured-gradle-plugin/build.gradle.kts[73-92]
.github/workflows/publish.yml[43-54]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The PR disables the marker publications’ Maven Central publish tasks, relying on the Gradle Plugin Portal (`publishPlugins`) for plugin id resolution. However, the current release workflow only runs `publishToMavenCentral`, so a tagged release will no longer publish plugin markers anywhere (Central markers disabled; Portal publish never executed), breaking `plugins { id(...) version "..." }` for consumers.

### Issue Context
- Marker->Central tasks are disabled in `featured-gradle-plugin/build.gradle.kts`.
- `.github/workflows/publish.yml` publishes only to Maven Central.

### Fix Focus Areas
- .github/workflows/publish.yml[43-54]
- build.gradle.kts[17-23]

### What to change
1. Add a `publishPlugins` step to `.github/workflows/publish.yml`, gated on Portal credentials (e.g., `ORG_GRADLE_PROJECT_gradle.publish.key` / `ORG_GRADLE_PROJECT_gradle.publish.secret`, or env vars mapped to them).
2. Optionally add a root-level `publishPlugins` aggregator task (similar to `publishToMavenCentral`) that depends on the included build task `:featured-gradle-plugin:publishPlugins`, so CI can run `./gradlew publishPlugins` consistently.
3. Ensure the Portal step runs on tags (releases) and fails fast if credentials are missing (or is explicitly skipped with a clear log message when not present, depending on desired policy).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[Copilot]

Pull request overview

This PR adjusts the Gradle plugin’s publishing setup so the plugin marker artifacts generated by java-gradle-plugin are published to the Gradle Plugin Portal (via publishPlugins), while Maven Central carries only the clean implementation artifact (dev.androidbroadcast.featured:featured-gradle-plugin).

Changes:

• Add the com.gradle.plugin-publish plugin to the Gradle plugin build and provide required Portal metadata (website/vcsUrl, per-plugin displayName/description/tags).
• Disable only the PublishToMavenCentralRepository tasks for *PluginMarkerMavenPublication so marker artifacts no longer end up in the Maven Central staging/bundle.
• Add a version-catalog entry for the plugin-publish plugin.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
gradle/libs.versions.toml	Adds version-catalog coordinates for com.gradle.plugin-publish.
featured-gradle-plugin/build.gradle.kts	Applies plugin-publish metadata and disables marker → Maven Central publish tasks while leaving the implementation publication enabled.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[qodo-code-review]

1. Portal publish not automated 🐞 Bug ☼ Reliability

featured-gradle-plugin disables publishing plugin-marker artifacts to Maven Central, but the
release workflow still only runs publishToMavenCentral. This will ship a release where the plugin
ids are not published to the Gradle Plugin Portal (no publishPlugins run), so consumers using the
plugins {} DSL won’t be able to resolve the plugin.

Agent Prompt

### Issue description
The PR disables the marker publications’ Maven Central publish tasks, relying on the Gradle Plugin Portal (`publishPlugins`) for plugin id resolution. However, the current release workflow only runs `publishToMavenCentral`, so a tagged release will no longer publish plugin markers anywhere (Central markers disabled; Portal publish never executed), breaking `plugins { id(...) version "..." }` for consumers.

### Issue Context
- Marker->Central tasks are disabled in `featured-gradle-plugin/build.gradle.kts`.
- `.github/workflows/publish.yml` publishes only to Maven Central.

### Fix Focus Areas
- .github/workflows/publish.yml[43-54]
- build.gradle.kts[17-23]

### What to change
1. Add a `publishPlugins` step to `.github/workflows/publish.yml`, gated on Portal credentials (e.g., `ORG_GRADLE_PROJECT_gradle.publish.key` / `ORG_GRADLE_PROJECT_gradle.publish.secret`, or env vars mapped to them).
2. Optionally add a root-level `publishPlugins` aggregator task (similar to `publishToMavenCentral`) that depends on the included build task `:featured-gradle-plugin:publishPlugins`, so CI can run `./gradlew publishPlugins` consistently.
3. Ensure the Portal step runs on tags (releases) and fails fast if credentials are missing (or is explicitly skipped with a clear log message when not present, depending on desired policy).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools