skip to content

How do you apply the signing plugin, and what tasks does it create and hook into the build lifecycle?

level: juniorimportance: should knowfreq 30%

answer

  1. core plugin, no version
  2. plugins { signing }
  3. Sign task per sign(...) call
  4. signMavenPublication
  5. publish dependsOn Sign

basics

~20 s

Apply it with plugins { signing }. It adds a signing { } block and creates a Sign task per signed publication (e.g. signMavenPublication), which the publish tasks depend on so signing runs before upload.

solid answer

~40 s

You apply the plugin through the plugins DSL — `plugins { signing }` in Kotlin or `id 'signing'` in Groovy; it's a **core** Gradle plugin so no version is needed. Applying it adds the `signing` extension (the `signing { }` configuration block) and the ability to create `Sign` tasks. Those tasks aren't created until you call `sign(...)`; each `sign(publishing.publications["maven"])` produces a task named `signMavenPublication`. The plugin also wires lifecycle dependencies: the `maven-publish` publish tasks (`publishMavenPublicationTo<Repo>Repository`, `publishToMavenLocal`) are made to depend on the relevant `Sign` task, guaranteeing signatures exist before upload. You can also run signing standalone — `./gradlew signMavenPublication` — to produce the `.asc` files without publishing, which is handy for verifying your key setup.

code

kotlin · 8 lines
kotlin
plugins {
  `maven-publish`
  signing   // core plugin, no version needed
}

signing { sign(publishing.publications["maven"]) }
// task created: signMavenPublication
// publishMavenPublicationTo...Repository dependsOn signMavenPublication

go deeper

for a junior

Apply with plugins { signing } and know signMavenPublication is created.

for a middle

Explain the sign(...)-creates-a-task model and the automatic publish-dependsOn-sign wiring.

for a senior

Note core-plugin status, task naming convention, and why Sign tasks aren't cacheable.

for a principal

Encapsulate the apply+wiring in a shared convention plugin for all publishable modules.

## Applying it It's a core plugin bundled with Gradle, so: ```kotlin plugins { `maven-publish` signing } ``` No external dependency or version is required. Applying it does two things: registers the `signing` **extension** (so the `signing { }` DSL block is available) and enables creation of `Sign`-type tasks. ## Tasks created No `Sign` task exists until you ask for one. Each `sign(...)` call creates a task: - `sign(publishing.publications["maven"])` → task `signMavenPublication` - `sign(configurations["archives"])` → task `signArchives` - `sign(someTask)` / `sign(file)` → correspondingly named tasks The naming convention is `sign` + the capitalized name of the thing being signed. ## Lifecycle wiring The plugin integrates with `maven-publish`: it makes each `publish...` task **dependsOn** the matching `Sign` task. So `./gradlew publish` always signs before uploading. There's also an ordering rule so signing happens after the artifacts are built. This automatic wiring is why you rarely set `dependsOn` manually for signing. ## Running it ```bash ./gradlew signMavenPublication # produce .asc only ./gradlew publish # build -> sign -> upload ./gradlew tasks --group=other # the sign tasks appear here ``` ## Inputs / caching note `Sign` tasks depend on the artifacts (their inputs) and on the key material. Because signing is non-deterministic (a fresh signature each run) it isn't a cacheable task; it simply re-runs when inputs change.

  • Do you need a version for the signing plugin?
    No — it's a core plugin bundled with the Gradle distribution, so `plugins { signing }` needs no version.
  • Are `Sign` tasks created just by applying the plugin?
    No. Applying it only adds the `signing` extension. A `Sign` task is created per `sign(...)` call, e.g. `signMavenPublication`.

saying these in an interview costs you the question

  • Adding a version or external coordinate for the signing plugin — it's core.
  • Manually adding `dependsOn` between publish and sign tasks; the plugin already wires it.

context

resolving links…