Import log4j-bom before Spring Boot in published BOMs

[jamesfredley]

Description

Slim residual for CVE-2026-49844 after Log4j 2.25.5 management already landed on 8.0.x.

This PR only ensures every published Grails BOM imports log4j-bom before Spring Boot (and before inherited Grails / Micronaut platforms) so Maven consumers resolve the full Log4j family to 2.25.5, including modules Grails does not constrain directly (for example log4j-layout-template-json).

Touched BOMs:

• grails-gradle-bom
• grails-base-bom / grails-bom (via base)
• grails-hibernate5-bom
• grails-hibernate7-bom
• grails-micronaut-bom
• grails-hibernate5-micronaut-bom
• grails-hibernate7-micronaut-bom

dependencies.gradle only adjusts combinedPlatforms ordering so docs / property extraction match the same Log4j-first platform order. Version pins and module constraints are unchanged.

Out of scope (handled elsewhere)

Jansi / Grails console / CLI classpath work is not in this PR.

That work lives in #16078 (Remove Jansi and separate CLI from production classpath), which:

• removes FuseSource Jansi entirely (does not swap to org.jline:jansi)
• moves console / CLI types onto the CLI tier
• enforces production classpath hygiene

Once #16078 merges, the Jansi half of the original #16044 scope is obsolete. This branch no longer documents or exempts Jansi CVEs.

Stacking

Does not need to stack on #16078. The two changes are independent and can merge in either order.

Verification

• Staged change is import-order only across the published BOM projects listed above.
• Base BOM skips log4j2-bom in the remaining platform loop to avoid a duplicate Maven import.
• No Jansi / vulnerability-exemption edits remain on this branch.

No user-facing API changes. No application docs required beyond what #16078 covers for CLI/Jansi.

Generative AI tooling was used to assist with residual-scope analysis and PR preparation. The resulting changes were reviewed and verified by the submitter.

[Copilot]

Pull request overview

Updates Grails’ published BOMs and internal vulnerability-scan configuration to remediate a Log4j CVE by overriding Spring Boot’s managed Log4j version, and to document/handle an unfixed Jansi CVE via OSS Index exclusions.

Changes:

• Bumps/introduces log4j2.version to 2.25.5, adds log4j-bom to the managed platform definitions, and explicitly manages key Log4j modules via the shared property.
• Imports the Log4j BOM ahead of the Spring Boot BOM in grails-gradle-bom and grails-base-bom to align Maven BOM import precedence.
• Adds an OSS Index exclusion entry for org.fusesource.jansi:jansi:2.4.2 with documentation of the unfixed CVE and removal conditions.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
grails-gradle/bom/build.gradle	Imports log4j-bom before spring-boot-dependencies in the Gradle BOM project.
grails-bom/base/build.gradle	Imports log4j-bom before spring-boot-dependencies in the base BOM project.
dependencies.gradle	Adds log4j2.version=2.25.5, registers log4j-bom as a platform, and adds Log4j module coordinates + combined platform registration.
build-logic/plugins/src/main/groovy/org/apache/grails/buildsrc/VulnerabilityScanPlugin.groovy	Documents/excludes the unfixed Jansi CVE coordinate from OSS Index findings.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bito-code-review]

The observation regarding the Jansi version discrepancy is accurate. The current exemption in VulnerabilityScanPlugin.groovy only covers org.fusesource.jansi:jansi:2.4.2, which leaves modules resolving 2.4.1 (as pinned in gradle.properties) vulnerable to scan failures. It is recommended to either add org.fusesource.jansi:jansi:2.4.1 to the exemption list or align all projects to use the same version.

build-logic/plugins/src/main/groovy/org/apache/grails/buildsrc/VulnerabilityScanPlugin.groovy

'org.fusesource.jansi:jansi:2.4.2',
            'org.fusesource.jansi:jansi:2.4.1',

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.8820%. Comparing base (4dc7e30) to head (03999f4).
⚠️ Report is 15 commits behind head on 8.0.x.

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #16044        +/-   ##
==================================================
- Coverage     51.8852%   51.8820%   -0.0031%     
- Complexity      18122      18123         +1     
==================================================
  Files            2046       2046                
  Lines           96278      96278                
  Branches        16729      16729                
==================================================
- Hits            49954      49951         -3     
- Misses          38951      38954         +3     
  Partials         7373       7373                

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jdaugherty]

It looks jline’s fork is the maintained version. We updated our dependencies in 8.x, so I don’t understand why we haven’t adopted the updated version that is maintained

[borinquenkid]

Following up on @jdaugherty's comment: #16079 migrates Grails to the maintained org.jline:jansi fork (the one Groovy 5's groovysh already uses), so this repo's builds no longer resolve org.fusesource.jansi:jansi:2.4.2 at all. Once that lands, the Jansi exemption added here has nothing to exempt and this PR can slim down to the Log4j BOM changes, which are unaffected and still needed.

Note the existing org.fusesource.jansi:jansi:1.18 exemption on 8.0.x still has to stay either way — that finding comes from previously published Grails 6/7 artifacts pulled transitively on some scanned classpaths, which no change in this repo can fix.

[jdaugherty]

FYI: the only real reason this jansi version was required is because logback had the withJansi option- which we no longer default because spring handles this a different way. My other PR will be updated here shortly

[jdaugherty]

FYI: #16078 - this needs merged instead of the jansi changes. Jansi is abandoned on the fusesource coordinates. See PR for details of what was found.