Repository navigation
build: revisit the CycloneDX 2.4.1 pin once the Gradle 9.4.1 variant conflict is fixed #186
Description
Tracking issue so a deliberate workaround does not quietly become permanent.
Current state
org.cyclonedx.bom is pinned to 2.4.1 even though Spring Initializr ships 3.x for
Spring Boot 4. The pin exists because cyclonedx 3.x fails at configuration time on Gradle
9.4.1 — a variant-mutation conflict on :cyclonedxDirectBom.
The cost of the pin is not just the old version. Spring Boot's CycloneDxPluginAction only
auto-configures the plugin version it recognises (3.x), so with 2.4.1 unrecognised it leaves
cyclonedxBom at plugin defaults — writing build/reports/bom.json and scanning the wrong
configuration set. build.gradle.kts therefore reproduces that configuration by hand:
tasks.named<org.cyclonedx.gradle.CycloneDxTask>("cyclonedxBom") {
setOutputName("application.cdx")
includeConfigs.set(listOf("productionRuntimeClasspath"))
}That output name and configuration set are load-bearing: generateBinaryLicense's
completeness gate reads the SBOM at build/reports/application.cdx.json and compares it
against the shipped fat-jar classpath. If the SBOM silently moved or described a different
classpath, the LICENSE appendix would be wrong — and the gate exists precisely to stop that.
Why this needs a tracker rather than a comment
The rationale is documented in build.gradle.kts and AGENTS.md, so it is discoverable. What
is not discoverable is when it stops being necessary. Once cyclonedx 3.x configures cleanly on
the project's Gradle version, the right move is to drop both the pin and the manual
configuration and let Spring Boot auto-configure the task — but nothing will prompt anyone to
check.
What to do when picking this up
- Try removing the version pin and the
tasks.named<CycloneDxTask>block. - Confirm
./gradlew buildproducesbuild/reports/application.cdx.json(notbom.json). - Confirm the SBOM lists the Spring Boot 4 modular jars and no stale Jackson 2 entries.
- Confirm
generateBinaryLicensestill passes — it is the gate that catches a mis-scoped SBOM. - Confirm the actuator still serves
/actuator/sbom/applicationin thehttpprofile.
Context: the pin arrived with #23 (Spring Boot 4 + Spring AI 2.0 upgrade).
Activity
fix: correct observability docs and bump to Boot 4.1.1 / Spring AI 2.0.1
adityamparikh commentedon Aug 20, 2026
Checked, and the pin can be lifted — cyclonedx 3.4.1 configures cleanly on Gradle 9.4.1.
:cyclonedxDirectBom, the task named in the original justification, now runs without thevariant-mutation conflict.
Migration PR: adityamparikh/solr-mcp#100 (targets
sb4, the head branch of #23 —mainrunsBoot 3.5.x where 2.4.1 is auto-configured normally, so this is Boot-4-only).
Two things the checklist above didn't anticipate, both worth recording here:
1. The output path moved. 3.x writes to
build/reports/cyclonedx/application.cdx.json—one directory deeper than 2.x.
generateBinaryLicensedeclares that as an input, so removingthe pin alone fails the build immediately rather than silently producing a wrong SBOM.
buildSrc/.../license-notice.gradle.kts:96needs updating.2. Spring Boot auto-configures the name but not the scope. Step 3 of the checklist
("confirm the SBOM lists the Spring Boot 4 modular jars and no stale Jackson 2") turned out to
be the wrong thing to check. Boot 4 does recognise 3.x and names the file correctly. What it
doesn't set is
includeConfigs, and unscoped the SBOM picks up test-only dependencies:Since the SBOM is embedded and served from
/actuator/sbom/application, unscoped it wouldpublish a bill of materials for artifacts the binary doesn't contain. The LICENSE appendix is
not affected —
generateBinaryLicensefilters to the shipped classpath itself — so this isan SBOM-accuracy issue rather than a licensing-correctness one.
Also worth noting for anyone reading the old code: scoping moved onto the direct task in
3.x (
cyclonedxDirectBom/CyclonedxDirectTask), and the class renamed fromCycloneDxTaskto
CyclonedxDirectTask— lowercased.Verified by building both ways and diffing: 141 components either way, identical component
sets, identical generated LICENSE.
fix(build): unpin cyclonedx to 3.4.1 and restore the SBOM to shipped …
adityamparikh commentedon Oct 6, 2026
The pin is lifted on
sb4, the head branch of #23: dd47f9c movesorg.cyclonedx.bomto 3.4.1 and keepsincludeConfigsscoped toproductionRuntimeClasspath, so the embedded SBOM still describes only the shipped artifacts.mainstays on 2.4.1, which is the version Spring Initializr ships for Boot 3.5, so there is no workaround there.This can be closed once #23 merges.