build: revisit the CycloneDX 2.4.1 pin once the Gradle 9.4.1 variant conflict is fixed

[adityamparikh]

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

1. Try removing the version pin and the tasks.named<CycloneDxTask> block.
2. Confirm ./gradlew build produces build/reports/application.cdx.json (not bom.json).
3. Confirm the SBOM lists the Spring Boot 4 modular jars and no stale Jackson 2 entries.
4. Confirm generateBinaryLicense still passes — it is the gate that catches a mis-scoped SBOM.
5. Confirm the actuator still serves /actuator/sbom/application in the http profile.

Context: the pin arrived with #23 (Spring Boot 4 + Spring AI 2.0 upgrade).

[adityamparikh]

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 the
variant-mutation conflict.

Migration PR: adityamparikh/solr-mcp#100 (targets sb4, the head branch of #23 — main runs
Boot 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. generateBinaryLicense declares that as an input, so removing
the pin alone fails the build immediately rather than silently producing a wrong SBOM.
buildSrc/.../license-notice.gradle.kts:96 needs 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:

	shipped fat jar	unscoped SBOM	scoped
components	—	246	141
testcontainers artifacts	0	6	0

Since the SBOM is embedded and served from /actuator/sbom/application, unscoped it would
publish a bill of materials for artifacts the binary doesn't contain. The LICENSE appendix is
not affected — generateBinaryLicense filters to the shipped classpath itself — so this is
an 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 from CycloneDxTask
to CyclonedxDirectTask — lowercase d.

Verified by building both ways and diffing: 141 components either way, identical component
sets, identical generated LICENSE.