Hi Volkan, On 8.07.2025 09:29, Volkan Yazıcı wrote: > I could not resolve the `artifact:compare` failure on > `log4j-parent`. This is an important problem, but not > a release blocker, AFAICT.
Just to clarify—are you referring to the reproducibility issue in `log4j-bom`, or is this a separate problem you encountered with `org.apache.logging.log4j:log4j`? Once I gain a better understanding of what’s happening with these SBOMs, I plan to address the issue in the CycloneDX Maven Plugin. On a related note, I’ve been re-evaluating the usefulness of the “aggregate” SBOMs (`log4j-bom` and `log4j`): * These SBOMs don’t accurately describe the dependencies of `log4j-bom` or `log4j`. For POM files, the true dependencies are their parent POMs. * The way the `makeAggregateBom` goal is currently bound in the Maven lifecycle means that the generated SBOMs lack critical details—such as the checksums of Log4j’s binary artifacts—since the execution happens before those artifacts are built. * Even if we consider the aggregate SBOM to describe the build-time dependencies of the source archive, it still misses key components, including Maven plugins used in the build process and test/provided dependencies. Given these limitations, I’m considering replacing the `makeAggregateBom` execution with `makeBom`. This would generate SBOMs only for binary JARs, capturing the actual compile- and runtime-relevant dependencies for each artifact. What do you think? Piotr
