jamesfredley commented on PR #15625: URL: https://github.com/apache/grails-core/pull/15625#issuecomment-4366117705
@jdaugherty - rewritten and force-pushed as a single squashed commit ([7f753f8](https://github.com/jamesfredley/grails-core/commit/7f753f8be59701bd4b4b51d6b300ef36958e22cb)) addressing all of your feedback. Diff is now **+58 / -6** across 3 files (was +152 / -66). The earlier iterations were chasing the wrong problem. Once I went and read [`CyclonedxPlugin.apply()`](https://github.com/CycloneDX/cyclonedx-gradle-plugin/blob/cyclonedx-gradle-plugin-3.0.0/src/main/java/org/cyclonedx/gradle/CyclonedxPlugin.java) and [`BaseCyclonedxTask`](https://github.com/CycloneDX/cyclonedx-gradle-plugin/blob/cyclonedx-gradle-plugin-3.0.0/src/main/java/org/cyclonedx/gradle/BaseCyclonedxTask.java) directly, two things became obvious: ### 1. "why are we wiring the aggregate even?" We weren't, deliberately - `CyclonedxPlugin.apply()` registers it for us, unconditionally. Its body is literally: ```java public void apply(final Project project) { getProjectAndSubprojects(project).forEach(this::configureProject); // direct task per project ... registerCyclonedxAggregateBomTask(project, ...); // ALWAYS registers aggregate ... } ``` So **the only way to not wire the aggregate is to not apply `CyclonedxPlugin`**. The fix is one line: replace `project.pluginManager.apply(CyclonedxPlugin)` with a direct `project.tasks.register('cyclonedxDirectBom', CyclonedxDirectTask) { ... }`. The aggregate task is then never registered, Spring Boot 4's `CycloneDxPluginAction` never fires (it triggers via `withType(CyclonedxPlugin)`), and there is nothing to disable, exclude, or filter. That deletes `disableAggregateSbomGeneration`, the `jar.exclude('META-INF/sbom/**')`, and the `META-INF/sbom/**` runtime-classpath ignore in one stroke. ### 2. "we intentionally left build info out of our sbom because this process wasn't ready" `BaseCyclonedxTask` exposes `includeBuildSystem` as a first-class `Property<Boolean>` with default `true`. The plugin's CI auto-injection of the `build-system` externalReference (the GitHub Actions run URL) is gated on it. **Setting `includeBuildSystem.set(false)` is the supported plugin-level off switch**, and it matches your stated intent for the SBOM. The JSON post-processor doesn't need to know about it at all, so the `Set<String> externalRefTypesToStrip` parameter and the externalReferences filter block are gone. Net effect on `rewriteSbom`: it goes back to being the single inline closure it was before this PR, with no signature change and no extracted helper. That should resolve "the method changes can be reverted for an easier diff." ### 3. "This sounds like a groovy bug. shouldn't we open a ticket on this?" Yes - it's filed as **[GROOVY-11954](https://issues.apache.org/jira/browse/GROOVY-11954)** and already fixed upstream in Groovy 4.0.32, 5.0.6, and 6.0.0-alpha-1 ([apache/groovy#2484](https://github.com/apache/groovy/pull/2484)). Grails currently pins `groovy.version=4.0.31` and 4.0.32 has not yet been published to Maven Central, so the qualification stays in place for v8.0.0-M1; each `builder()` factory has a `TODO(GROOVY-11954)` note so a future Groovy bump can drop it trivially. Bytecode is unchanged either way. ### Verification - `:grails-bootstrap:tasks --all` shows `cyclonedxDirectBom` only - no `cyclonedxBom` aggregate - Two consecutive `:grails-bootstrap:jar --rerun-tasks` runs produce byte-identical jars (same SHA-256: `4FE425486AF7E77CC16117D899BFB7042B8292685237FEAAF17259E68FF87620`) - Produced jar contains only `META-INF/sbom.json`; no `META-INF/sbom/application.cdx.json` - No `build-system` externalReference anywhere in `metadata.component.externalReferences` - `serialNumber` is a deterministic `urn:uuid:...` (PR #15614's `projectPath`-into-UUID-seed mixing preserved unchanged) PTAL. -- 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]
