skip to content

Can a single build publish multiple plugins to the Portal, and how do you structure the `gradlePlugin` block to do so?

level: seniorimportance: nice to knowfreq 20%

answer

  1. multiple create(...) entries
  2. shared website/vcsUrl
  3. one impl JAR, one marker per id
  4. same group/version for all
  5. split into subprojects for independent versions

basics

~10 s

Yes. Declare each plugin as a separate entry in the gradlePlugin { plugins { … } } block with its own id, implementationClass, displayName, description, and tags. One publishPlugins run uploads all of them.

solid answer

~40 s

A single project can ship multiple plugins to the Portal. Inside **`gradlePlugin { plugins { … } }`** you add one named entry per plugin, each with its own `id`, `implementationClass`, `displayName`, `description`, and `tags`. The shared **`website`** and **`vcsUrl`** are set once on the extension. Running **`publishPlugins`** publishes the **single implementation artifact** (your project JAR containing all plugin classes) plus **one marker artifact per `id`** — so each ID is independently resolvable via `plugins {}` while sharing the same underlying JAR. This is the standard pattern for a 'suite' plugin or a base+convention pair. Keep IDs in the same namespace and ensure `project.version` is consistent, since every marker tracks it.

code

kotlin · 16 lines
kotlin
gradlePlugin {
    website = "https://example.com/tools"
    vcsUrl = "https://github.com/example/tools.git"
    plugins {
        create("base") {
            id = "com.example.base"
            implementationClass = "com.example.BasePlugin"
            displayName = "Base"; description = "Conventions"; tags = listOf("base")
        }
        create("reporting") {
            id = "com.example.reporting"
            implementationClass = "com.example.ReportingPlugin"
            displayName = "Reporting"; description = "Reports"; tags = listOf("reporting")
        }
    }
}

go deeper

for a junior

Know it's possible — add another entry to the plugins block.

for a middle

Explain the shared extension metadata plus per-plugin entries and that one run publishes all.

for a senior

Articulate that all plugins share one JAR and one version, with one marker per ID, and when to split into subprojects.

for a principal

Decide suite-vs-split architecture across a plugin catalog, balancing cohesion against independent versioning/governance.

## Multiple plugins, one build The `gradlePlugin.plugins` container is a `NamedDomainObjectContainer` — you can register as many plugin declarations as you like: ```kotlin gradlePlugin { website = "https://example.com/tools" vcsUrl = "https://github.com/example/tools.git" plugins { create("base") { id = "com.example.base" implementationClass = "com.example.BasePlugin" displayName = "Base" description = "Shared conventions" tags = listOf("conventions") } create("reporting") { id = "com.example.reporting" implementationClass = "com.example.ReportingPlugin" displayName = "Reporting" description = "Adds reports" tags = listOf("reporting") } } } ``` ## What gets published - **One implementation artifact** — your project's JAR holds *all* plugin classes (`BasePlugin`, `ReportingPlugin`). They aren't split into separate JARs by default. - **One marker per ID** — `com.example.base:com.example.base.gradle.plugin` and `com.example.reporting:com.example.reporting.gradle.plugin`, each pointing at that same implementation JAR. This means a consumer applying only `com.example.reporting` still pulls the full JAR (which also contains `BasePlugin`); the marker just routes the ID. If you want truly independent artifacts, split into separate subprojects/builds instead. ## When to use this - A **base/convention pair** where one plugin applies the other. - A **plugin suite** with closely related plugins sharing code. ## Caveats - All plugins share the project's `group`/`version`; you can't version them independently within one build. - Each ID gets its own Portal listing (own displayName/description/tags), so search/discovery is per-ID. - One `publishPlugins` invocation uploads the whole set atomically.

  • If a consumer applies only one of the two plugins, do they avoid downloading the other's code?
    No. Both plugins live in the same implementation JAR by default, so the full JAR is downloaded regardless. The marker only routes the ID to that shared artifact. Separate JARs require separate subprojects/builds.
  • Can you version the two plugins independently in the same build?
    Not within a single build — they share `project.version`, which also drives every marker version. Independent versioning requires separate projects.

saying these in an interview costs you the question

  • Claiming each plugin gets its own JAR by default.
  • Saying you can give plugins in one build different versions.
  • Forgetting markers are still one-per-id.

context

resolving links…