Let a publication describe what its SBOM lists

[alexander-yevsyukov]

Closes #768.

Problem

PublicationSbom (#764) writes the SBOM of every JVM publication from runtimeClasspath. That is right for a publication made from a software component, whose POM Gradle derives from the same declarations. It is wrong for a publication made with artifact(...), which is how custom publications and uber-jar-module publish:

• a POM written by hand declares dependencies that no Gradle-based tool sees, so the SBOM missed them. For example, core-jvm-gradle-plugin lacked core-jvm-plugins, its main runtime dependency.
• modules and libraries packed into the JAR were listed as DEPENDS_ON dependencies. uber-jar-module has an empty POM, yet its SBOM listed every bundled library.

A module could not correct this itself.

What changes

A publication can now describe what its SBOM lists:

create<MavenPublication>("fatJar") {
    artifact(tasks.shadowJar)
    sbom {
        dependencies(fatJarDependencies) // the configuration the POM declares; default: `runtimeClasspath`
        bundled(tasks.shadowJar)         // or `bundled(configuration)`, for other packing
    }
}

• The artifact DEPENDS_ON the graph of dependencies.
• A bundled component is CONTAINS from the artifact, and never DEPENDS_ON from it.
• A component resolved only to find the bundled ones, and not bundled itself, is left out, with its relationships and license texts.
• The plugin walks the configurations of the SBOM one after another, through the packages it already knows. So its walk of the bundled content can hang a component under a dependency whose POM excludes it. Such edges are dropped.
• uber-jar-module declares bundled(tasks.shadowJar) for its fatJar.
• Publications without sbom { } get the same SBOM as before, with no new task input. This was verified byte for byte against Publish an SPDX SBOM with each Maven publication #764's SBOMs of core-jvm-compiler.

The pieces:

• SbomContent.kt: the public DSL.
• ArtifactComponents.kt: the rewrite of the SPDX document.
• ComponentKey.kt: the key of a component, alike from Gradle's graph and from an SPDX package.
• SpdxField.kt: the SPDX field names.
• PublicationSbom.kt: choosing the SPDX target, and building lazy providers. A publication gets an SPDX target of its own only when its configurations differ from those of its module. Nothing is resolved in the root projectsEvaluated hook: each module's own SBOM task resolves its configurations.

Verification

• ./gradlew :buildSrc:build detekt passes with 144 tests. PublicationSbomIgTest gains three fixture modules:

  • thin: a thin JAR with a hand-written POM that packs a sibling.
  • fat: a Shadow fat JAR with a dependency filter and a hand-written POM, including the edge-leak case.
  • uber: the uber-jar-module pattern.

  ArtifactComponentsSpec covers the rewrite on hand-written SPDX documents.

• core-jvm-compiler, smoke-tested in a scratch clone of publish-sboms, with step 3 of the issue simulated by POM-mirror configurations and sbom { }:

  • core-jvm-gradle-plugin DEPENDS_ON exactly core-jvm-plugins and kotlinpoet-ksp, and CONTAINS grpc, ksp and routing.
  • core-jvm-plugins lists 24 of its 25 POM dependencies as DEPENDS_ON, and 26 bundled components as CONTAINS.

• tool-base, smoke-tested in a scratch clone: intellij-platform and intellij-platform-java CONTAIN exactly the JetBrains artifacts their Shadow include filter admits. Two other modules could not be built: syncing the current buildSrc brings a kotlinx-coroutines-bom 1.11.0 vs 1.10.2 conflict, unrelated to this change.

Notes for reviewers

• The bundled content comes from what Shadow is given, not from the JAR's entries. ShadowJar.includedDependencies, the files its dependency filter leaves in, is Shadow's only public view of what it packs. So a module whose classes are stripped by path still counts as bundled. A module that the POM declares must be excluded with the dependency filter; the KDoc of bundled(TaskProvider<ShadowJar>) says so.
• core-jvm-compiler follow-up (step 3 of the issue):
  • Its fat JAR is given the files of five Gradle plugins its POM declares: compiler-gradle-plugin, compiler-gradle-api, time-gradle-plugin, validation-gradle-plugin and protobuf-gradle-plugin. They belong in pomProvidedModules. With that, none of its POM dependencies is reported as bundled, and verifyBundledPackages still passes.
  • The KSP Gradle plugin marker in its POM is a POM-only artifact, so the SPDX plugin lists no package for it. It lists the marker's content, symbol-processing-gradle-plugin, instead.
• The SPDX plugin records only the first path to each package. So some dependencies a POM declares hang under the package through which they were first found, not directly under the artifact. Every SBOM the plugin writes has that shape; this PR does not change it.
• The .agents/tasks/ plan is in the branch, to be deleted once this merges. The second commit adds a team memory about choosing file boundaries by design rather than by detekt's size thresholds.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-25T17:39:03.115674Z	d4eae1c	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[Copilot]

Copilot review overview

🟢 Approval recommended

Only minor documentation and API-clarity nits remain; no approval-blocking issues were identified.

Review effort: Lite
Findings: 1

Open (1)

• Clarify replacement versus accumulation semantics for dependency methods · New

What changed in this PR

Adds per-publication SBOM configuration to distinguish declared dependencies from bundled JAR contents, with SPDX rewriting and comprehensive tests.

Changes:

• Adds sbom { dependencies(...) / bundled(...) } DSL.
• Updates publication and uber-JAR SBOM generation.
• Adds unit, integration, and supporting documentation coverage.
• Two minor documentation/API clarity nits remain.

File	Summary
buildSrc/​src/​test/​kotlin/​io/​spine/​gradle/​publish/​PublicationSbomIgTest.kt	Adds integration coverage for custom and bundled publications.
buildSrc/​src/​test/​kotlin/​io/​spine/​gradle/​publish/​ArtifactComponentsSpec.kt	Tests SPDX relationship rewriting.
buildSrc/​src/​main/​kotlin/​uber-jar-module.gradle.kts	Marks uber-JAR contents as bundled.
buildSrc/​src/​main/​kotlin/​io/​spine/​gradle/​publish/​SpinePublishing.kt	Documents custom SBOM configuration.
buildSrc/​src/​main/​kotlin/​io/​spine/​gradle/​publish/​SpdxField.kt	Centralizes SPDX field names.
buildSrc/​src/​main/​kotlin/​io/​spine/​gradle/​publish/​SbomContent.kt	Defines the public SBOM DSL.
buildSrc/​src/​main/​kotlin/​io/​spine/​gradle/​publish/​PublicationSbomTask.kt	Applies publication-specific SBOM metadata.
buildSrc/​src/​main/​kotlin/​io/​spine/​gradle/​publish/​PublicationSbom.kt	Registers publication-specific SBOM inputs and targets.
buildSrc/​src/​main/​kotlin/​io/​spine/​gradle/​publish/​ComponentKey.kt	Matches Gradle components to SPDX packages.
buildSrc/​src/​main/​kotlin/​io/​spine/​gradle/​publish/​ArtifactComponents.kt	Rewrites dependency and containment relationships.
.agents/​tasks/​sbom-custom-publications.md	Records implementation design and verification.
.agents/​memory/​MEMORY.md	Registers design guidance.
.agents/​memory/​feedback/​design-over-detekt-thresholds.md	Documents file-boundary guidance.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.