jamesfredley commented on PR #15614: URL: https://github.com/apache/grails-core/pull/15614#issuecomment-4357183912
Pushed [`4d1a78f1e2`](https://github.com/apache/grails-core/pull/15614/commits/4d1a78f1e2) - second-order fix for `com.gradleup.shadow` fat jars. ## Why a follow-up commit The `projectPath`-seed fix in `d6a80e0c9e` made each project's *own* `cyclonedxDirectBom` output unique and reproducible, but it did not change how the shadow plugin merges sibling jars. When I extracted `META-INF/sbom.json` from the fat jars produced by `:grails-cli` and `:grails-cli-shadow` after the first fix, both still had: | Jar | `serialNumber` | `metadata.component.name` | |---|---|---| | `grails-cli-8.0.0-SNAPSHOT-all.jar` | `urn:uuid:631bbcd5-...` | `grails-shell-cli` | | `grails-cli-shadow-8.0.0-SNAPSHOT-all.jar` | `urn:uuid:631bbcd5-...` | `grails-shell-cli` | Two distinct fat jars sharing one UUID, both attributed to the wrong module - because shadow's first-wins merge picked up `grails-shell-cli`'s `META-INF/sbom.json` (a transitive dep) before either fat-jar project's own SBOM. Same CycloneDX 1.6 violation, different cause. ## What changed 1. `SbomPlugin.publishSbomForShadowJarProjects` (new) - symmetrical to `publishSbomForJarProjects`. When a project applies `com.gradleup.shadow`, its `shadowJar` task now `exclude`s incoming `META-INF/sbom.json` from the merge and `from`s the project's own `cyclonedxDirectBom` output, plus sets the same `Sbom-Location` / `Sbom-Format` manifest attributes the regular jar already gets. Uses the broad `Task` type with a cast to `Jar` so build-logic does not need a compile-time dep on the shadow plugin types. 2. `grails-forge/grails-cli-shadow/build.gradle` - that module does not apply `org.apache.grails.buildsrc.sbom` (it is an intermediate build artifact, not published), so the SbomPlugin hook does not fire for it. Its `shadowJar` exclude list now drops `META-INF/sbom.json` directly so the intermediate fat jar - which feeds `:grails-cli`'s `shadowCombined` configuration - cannot smuggle a wrong SBOM back in. ## Verification (Gradle 9.4.1, `SOURCE_DATE_EPOCH=git log -1 --pretty=%ct`, `--no-build-cache --rerun-tasks`) After the second fix, `META-INF/sbom.json` in each CLI jar: | Jar | `serialNumber` | `metadata.component.name` | |---|---|---| | `:grails-shell-cli` (regular) | `631bbcd5-...` | `grails-shell-cli` | | `:grails-wrapper` (regular) | `9c5f6980-...` | `grails-wrapper` | | `:grails-cli` (regular) | `3e4ea827-...` | `grails-cli` | | `:grails-cli` (`-all` FAT) | `3e4ea827-...` | `grails-cli` | | `:grails-cli-shadow` (regular, empty) | _(no SBOM)_ | _(no SBOM)_ | | `:grails-cli-shadow` (`-all` FAT) | _(no SBOM - excluded)_ | _(no SBOM)_ | | `:grails-forge-cli` (regular) | `890372ec-...` | `grails-forge-cli` | Four distinct `serialNumber` values across four user-facing jars; zero cross-module collisions. `:grails-cli`'s regular and `-all` jar share a `serialNumber` *by design* - they ship the same project's SBOM, the `-all` jar just adds bundled classes; CycloneDX uniqueness applies across BOMs describing different artifacts, not across two jars whose embedded BOM describes the same project. Smoke tests against the same flow `verify-cli-distribution.sh` runs: - `apache-grails-8.0.0-SNAPSHOT-bin.zip` extracts cleanly, `LICENSE` and `NOTICE` present, `bin/` populated. - `grails-shell-cli --version` => `Grails Version: 8.0.0-SNAPSHOT`, exit 0. - `grails-forge-cli --version` => `Grails Version: 8.0.0-SNAPSHOT`, exit 0. - `grails-shell-cli create-app ShellApp` generates a complete Grails app, exit 0. - `grails-forge-cli create-app -x -g mongodb -f gradle-settings-file ForgeApp` generates a complete Grails app, exit 0. - `java -jar grails-cli-8.0.0-SNAPSHOT-all.jar --version` still launches the CLI with the new SBOM in place, exit 0. `apache-grails-wrapper-8.0.0-SNAPSHOT-bin.zip` also extracts cleanly with `LICENSE`, `NOTICE`, `grailsw`, `grailsw.bat`, `grails-wrapper.jar` present. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
