fix: Define version of error_prone_annotations in parent POM

[ppkarwasz]

This change explicitly defines the version of the error_prone_annotations dependency in the log4j parent POM.

Previously, the version was inherited via the error-prone.version property from logging-parent. However, because the log4j-bom POM is flattened during publication, this property no longer resolves in consumer projects.

Fixes #3779

[Copilot]

Pull Request Overview

This PR explicitly defines the version of the error_prone_annotations dependency in the log4j parent POM to ensure consumers no longer inherit an undefined property when the BOM is flattened.

• Added a new <error-prone-annotations.version> property in log4j-parent/pom.xml
• Updated the managed dependency to use the new property
• Extended the changelog entry to include issue 3779 and updated its description

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/changelog/.2.x.x/3758_fix_jspecify_dep.xml	Added issue 3779 and broadened the description for both fixes
log4j-parent/pom.xml	Defined error-prone-annotations.version and updated dependency reference

Comments suppressed due to low confidence (2)

src/changelog/.2.x.x/3758_fix_jspecify_dep.xml:9

• [nitpick] The changelog entry for issue 3779 is appended to a file named after issue 3758, which may be confusing. Consider creating a separate file (e.g., 3779_fix_error_prone_annotations_version.xml) or renaming the existing file to reflect both issue IDs.

    <issue id="3779" link="https://github.com/apache/logging-log4j2/issues/3779"/>

log4j-parent/pom.xml:83

• [nitpick] The property name uses hyphens while the artifactId uses underscores (error_prone_annotations). For consistency and to avoid confusion, consider aligning the property name with the artifactId (e.g., error_prone_annotations.version).

    <error-prone-annotations.version>2.38.0</error-prone-annotations.version>

[ppkarwasz]

Unfortunately, this PR did not resolve #3779. I mistakenly applied the new error-prone-annotations.version property only to the Gradle Module Metadata plugin configuration:

logging-log4j2/log4j-parent/pom.xml

Lines 1110 to 1114 in 65d30ee

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

The Maven dependency configuration still relies on the inherited error-prone.version, which is later trimmed by the Flatten Maven Plugin:

logging-log4j2/log4j-parent/pom.xml

Lines 859 to 864 in 65d30ee

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

The intention behind introducing a separate error-prone-annotations.version property—rather than overriding error-prone.version—was to avoid false positives, since error-prone.version is defined during the build but stripped afterward. However, this workaround seems to have backfired.

This highlights a deeper issue: the problem is difficult to reliably reproduce or detect:

• Maven ignores the provided scope for dependencies in many contexts.
• Gradle uses its own .module metadata and doesn't seem to be affected, as confirmed by the success of our Gradle integration test in release build 16091508381.

I'm open to suggestions on how we might better catch issues like this in the future—especially around metadata mismatches and flattened POM artifacts.