jamesfredley commented on PR #15614: URL: https://github.com/apache/grails-core/pull/15614#issuecomment-4363669051
@jdaugherty pushed [1144b74e8a](https://github.com/apache/grails-core/pull/15614/commits/1144b74e8acf8b0086e5241ff0ab57b8a84e055a) addressing all five threads from your review. ## Diffstat `` build-logic/.../SbomPlugin.groovy | 5 +---- grails-forge/grails-cli-shadow/build.gradle | 7 +------ grails-forge/grails-cli/build.gradle | 21 ++++----------------- 3 files changed, 6 insertions(+), 27 deletions(-) `` ## Per-thread summary | # | Thread | Change | |---|---|---| | 1 | `SbomPlugin.groovy` "restore the original comment" | Reverted to one-liner `// sboms are only published to Grails jar files at this time`. | | 2 | `grails-cli-shadow/build.gradle` "we don't need such a long comment" | Replaced with `'META-INF/sbom.json', // intermediate build, exclude conflicting files`. | | 3 | `grails-cli/build.gradle` "Move this into the configure" | `cyclonedxDirectBomTask` is now declared inside the `shadowJar` configure block, behind the `skipJavaComponent` guard (its only caller). | | 4 | `grails-cli/build.gradle` "flatMap is non lazy; isnt the json output the only output?" | Switched to `it.from(cyclonedxDirectBomTask)`. `BaseCyclonedxTask` does declare two `@OutputFile` properties (`jsonOutput` / `xmlOutput`) but `SbomPlugin` calls `xmlOutput.unsetConvention()` and only ever sets `jsonOutput`, so it is the only effective output. | | 5 | `grails-cli/build.gradle` "Is this added by the cyclonedx plugin already? Did you check the manifest files? Do we do this anywhere else?" | (a) No, cyclonedx-gradle-plugin does not touch `MANIFEST.MF`. (b) Verified `Sbom-Location` / `Sbom-Format` appear in both `grails-cli-...jar` and `grails-cli-...-all.jar` after the change. (c) Yes, `SbomPlugin.publishSbomForJarProjects` does the same on the regular jar, so the shadow path mirrors that for downstream SBOM discovery. Manifest block kept. | ## Verification (Gradle 9.4.1, `--rerun-tasks` x2) | Jar | `serialNumber` | `component.name` | |---|---|---| | `:grails-cli` regular jar | `urn:uuid:beabd2c0-0175-3997-bae5-bb8dd245f97b` | `grails-cli` | | `:grails-cli` `-all` fat jar | `urn:uuid:beabd2c0-0175-3997-bae5-bb8dd245f97b` | `grails-cli` | | `:grails-cli-shadow` `-all` fat jar | _(no SBOM, excluded as designed)_ | _(no SBOM)_ | | `:grails-bootstrap` regular jar | `urn:uuid:3fe6e19d-48e4-3097-810e-1b504da46be6` | `grails-bootstrap` | * `:grails-bootstrap` matches byte-for-byte the value in the original PR description, confirming end-to-end reproducibility across the full build is preserved. * Same `serialNumber` between the regular and `-all` jars of `:grails-cli` is by design (same project's SBOM); no collisions across distinct projects. * Shadow fat jar manifest contains `Sbom-Location: META-INF/sbom.json` and `Sbom-Format: CycloneDX`. ## On the test failures you flagged The three failing checks on the previous head (`23f586d4f6`) are infrastructure-only, not caused by this PR: * `Build Grails-Core (macos-latest, 21)` failed with `java.net.UnknownHostException: repository.apache.org: nodename nor servname provided, or not known` while resolving `grails-spring-security-rest-8.0.0-SNAPSHOT.jar` - GitHub Actions DNS hiccup against `repository.apache.org`. * `Build Grails-Core Rerunning all Tasks (ubuntu-latest, 21)` and `build_grails` show no test assertion failures in their logs - they timed out after `39m` / `55m` waiting on the same snapshot artifacts. The Linux 21/25 build, Windows 25, both Forge variants, all three Functional Tests matrices, both Hibernate5 matrices, all five MongoDB matrices, plus TestLens (`19783 executed` / `35/35 checks`) all passed on the previous commit, so the regression surface is empty. CI on `1144b74e8a` should run cleanly once the snapshot DNS recovers. Ready for re-review. -- 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]
