Log4j parent pom declares a dependency on com.google.errorprone:error_prone_annotations with an undefined version property

[wilkinsona]

Description

The dependency is defined using ${error-prone.version} for its <version>:

logging-log4j2/log4j-parent/pom.xml

Lines 859 to 864 in bda6336

	<dependency>
	<groupId>com.google.errorprone</groupId>
	<artifactId>error_prone_annotations</artifactId>
	<version>${error-prone.version}</version>
	<scope>provided</scope>
	</dependency>

No such property is defined in the pom. Depending on how the pom is consumed and how strictly it is validated, this causes problems for consumers.

The problem was introduced in e08c7ba where the property was renamed to error-prone-annotations.version.

Configuration

Version: 2.25.1

Operating system: Any

JDK: Any

[wilkinsona]

Sorry, I've just found #3779 which this issue duplicates. Unfortunately, we treat warnings as errors when building Spring Boot so the problem with the pom is blocking our upgrade to 2.25.x. We've rolled back to 2.24 for now.

[ppkarwasz]

Hi @wilkinsona,

As we’re not regular Gradle users, could you advise on how to configure our Gradle integration test (see apache/logging-log4j-samples#351) so that it fails on issues of this kind?

The problem is not visible in our main build. Our process relies on build POMs that are only flattened into the published consumer POMs at a later stage. As a result, only our integration tests are in a position to detect the issue. So far, the closest we’ve come is reproducing it as a log event with severity ERROR issued by the Spring Boot Dependency Management plugin, but that doesn’t actually fail the build since only exceptions or the ProblemReporter API seem to trigger a failure.

[wilkinsona]

So far, the closest we’ve come is reproducing it as a log event with severity ERROR issued by the Spring Boot Dependency Management plugin, but that doesn’t actually fail the build since only exceptions or the ProblemReporter API seem to trigger a failure.

That's how we noticed it in Boot's release process. We have a verification test that asserts that there's no error output. It failed due to Log4j's malformed pom.