Release
v3.4.0
lockstepLog4j joins the built-in coupled families: a vulnerable log4j-api now ships as one log4j-bom import that moves log4j-core with it, instead of a lone pin that leaves the family skewed. Also fixes the 3.3.1 duplicated netty-bom imports and empty maintenance MRs.
Highlights
- 01
One advisory, one BOM, the whole family
Log4j is one release train with one BOM, and the project's own guidance is to keep api and core at the same version. A transitively remediated member of org.apache.logging.log4j is now consolidated into a single log4j-bom import at the fix version, exactly as Jackson, Netty, Jetty, gRPC and Spring Security already are.
- 02
Why the governor could not find it
The governor pass only imports a BOM some carrier literally declares. Libraries depend on log4j-api directly and almost none import log4j-bom, so there was never a receipt to detect. Built-in families cover precisely the BOMs the ecosystem knows about but rarely declares.
Full notes
Added
- Log4j (org.apache.logging.log4j, governed by log4j-bom) is a built-in coupled family; the legacy log4j:log4j 1.x group is deliberately excluded. reg-099 proves the scenario against Maven Central.
Fixed
- Family-BOM imports Argus already authored are re-versioned in place instead of duplicated; cleanup reclaims already-shipped shadowed duplicates (reg-100), and comment-to-element pairing is byte-accurate.
- Empty-diff maintenance MRs are no longer published: the final pass drops artifacts identical to the current pom.xml, and the publisher skips commits with no net change against the target branch.