skip to content

What rules and conventions govern the plugin ID you publish to the Portal, and how do they affect namespace ownership?

level: middleimportance: should knowfreq 25%

answer

  1. reverse-domain dotted lowercase
  2. namespace first-come ownership
  3. org.gradle reserved
  4. id != Maven coordinates
  5. changing id = breaking change

basics

~10 s

Plugin IDs are reverse-domain dotted names (e.g. com.example.greeting). On the Portal the namespace (leading segments) is owned by the first publisher, so you must publish under a domain/group you control.

solid answer

~40 s

A plugin **ID** is a dot-separated, reverse-domain-style identifier like `com.example.greeting`. Lowercase alphanumeric segments separated by dots is the convention, and the **leading namespace** (e.g. `com.example`) is what consumers trust. On the Gradle Plugin Portal, **namespace ownership is first-come**: the first account to publish under a namespace effectively claims it, and the Portal restricts later publishers from squatting on it. The `org.gradle` namespace is reserved for core Gradle plugins. Practically: choose an ID under a domain or group you legitimately control, keep it stable (consumers pin to it in `plugins {}`), and use a distinct trailing segment per plugin. The `id` set in the `gradlePlugin` block is exactly what consumers write in `plugins { id("…") }`.

code

kotlin · 12 lines
kotlin
// id is independent of group/name; marker bridges them
group = "com.example"            // Maven group
version = "1.2.0"

gradlePlugin {
    plugins {
        create("greeting") {
            id = "com.example.greeting"   // what consumers write in plugins {}
            implementationClass = "com.example.GreetingPlugin"
        }
    }
}

go deeper

for a junior

Know IDs are reverse-domain dotted names like a Java package.

for a middle

Explain first-come namespace ownership, the org.gradle reservation, and that ID is independent of Maven coordinates.

for a senior

Discuss ID stability as an API contract and how the marker decouples ID from coordinates.

for a principal

Govern an org-wide plugin namespace strategy — reserving prefixes, naming conventions, and ownership across teams.

## Anatomy of a plugin ID A plugin ID is a sequence of lowercase, alphanumeric (plus `.`) segments in **reverse-domain** style: ``` com.example.greeting └──┬──┘ └──┬──┘ namespace name ``` It mirrors Java package naming. The Portal uses it both as the listing identity and to derive the **marker coordinates** (`com.example.greeting:com.example.greeting.gradle.plugin`). ## Namespace ownership on the Portal - **First-come ownership**: when you first publish under a namespace prefix, the Portal associates that namespace with your account and prevents other accounts from publishing colliding IDs (anti-squatting). - **Reserved**: `org.gradle.*` is reserved for Gradle's own core plugins — you cannot publish there. - **Choose what you control**: use a reverse-domain you own (your company/org domain) or your established group coordinates. This is both convention and a trust signal to consumers. ## Stability matters Consumers hard-code the ID in their `plugins {}` block: ```kotlin plugins { id("com.example.greeting") version "1.2.0" } ``` Changing an ID is a breaking change — it's effectively a new plugin with a new namespace/listing. Pick carefully up front. ## Relationship to coordinates The ID is **independent** from the implementation artifact's Maven coordinates (`group:name`). You might have `group = com.example`, `name = greeting-plugin`, but plugin `id = com.example.greeting`. The marker (derived from the ID) bridges them, so they don't have to match — though keeping the namespace aligned with your group aids clarity. ## Per-plugin uniqueness Within and across builds, each plugin needs a globally unique ID on the Portal. For a suite, share the namespace and vary the trailing name (`com.example.base`, `com.example.reporting`).

  • Does the plugin ID have to match the implementation artifact's Maven group?
    No. The ID and the `group:name` coordinates are independent; the plugin marker (derived from the ID) bridges to whatever coordinates the implementation uses. Aligning the namespace with your group is good practice but not required.
  • Why is changing a published plugin's ID considered a breaking change?
    Consumers reference the exact ID in their `plugins {}` block. A new ID is a new Portal listing/namespace and won't be picked up by existing builds, so all consumers must update.

saying these in an interview costs you the question

  • Claiming you can publish under `org.gradle.*`.
  • Saying the ID must equal the Maven coordinates.
  • Treating namespace as freely shareable across publishers.

context

resolving links…