Missing property in the log4j-parent pom file in version 2.25.0

[sasidhar-chittumuru-jemmic]

Description

error.prone.version property is being used in log4j-parent pom.xml file but this property in not defined and because of this log files are not generated for the spring boot application.

Configuration

Version:
Log4j 2.25.0
springboot : 2.7.18

Operating system: Ubuntu24.04

JDK: JDK 21.0.3

Logs

'dependencies.dependency.version' for com.google.errorprone:error_prone_annotations:jar must be a valid version but is '${error-prone.version}'. in org.apache.logging.log4j:log4j-web:2.25.0

[ppkarwasz]

Hi @sasidhar-chittumuru-jemmic,

error.prone.version property is being used in log4j-parent pom.xml file but this property in not defined and because of this log files are not generated for the spring boot application.

Great catch—thank you! This issue is related to #3758 and will be addressed in the upcoming 2.25.1 release, scheduled for early July. It is not the reason the Spring Boot configuration files (e.g. log4j2-spring.xml or the default Spring Boot configuration) are not used, but is a problem nevertheless.

Root Cause

The problem originates from our use of the Flatten Maven Plugin, which strips unnecessary elements from our POMs before they are published. The log4j-bom POM is significantly flattened, and in the process, its link to the logging-parent—which defines the error-prone.version property—is lost.

This issue isn't detected during the build because Maven computes the effective model of all modules in the reactor before any plugin (including flattening) is executed. As a result, the build sees the correct model, but the published POM is missing required metadata, leading to problems for consumers.

Possible Solutions

One way to catch this kind of issue would be to also flatten the log4j parent POM. Since the Flatten Maven Plugin would use the already-flattened log4j-bom, the missing error-prone.version would be detected as an error. However, this isn't a clean solution: flattening log4j would remove its own link to log4j-bom, introducing a different set of problems for child artifacts.

For now, the most pragmatic solution is to explicitly define error-prone.version in both log4j and logging-parent. This will restore stability without requiring deeper structural changes.

Longer term, we plan to resolve this class of issues more comprehensively by migrating to Maven 4 (#3780), which introduces a formal separation between build and consumer POMs, making this kind of workaround unnecessary.