ppkarwasz opened a new issue, #3822: URL: https://github.com/apache/logging-log4j2/issues/3822
Unfortunately, PR #3785 did **not** resolve #3779. I mistakenly applied the new `error-prone-annotations.version` property only to the Gradle Module Metadata plugin configuration: https://github.com/apache/logging-log4j2/blob/65d30ee65e110e0c241c33b34907874b6271f356/log4j-parent/pom.xml#L1110-L1114 The Maven dependency configuration still relies on the inherited `error-prone.version`, which is later trimmed by the Flatten Maven Plugin: https://github.com/apache/logging-log4j2/blob/65d30ee65e110e0c241c33b34907874b6271f356/log4j-parent/pom.xml#L859-L864 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](https://github.com/apache/logging-log4j2/actions/runs/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. _Originally posted by @ppkarwasz in https://github.com/apache/logging-log4j2/issues/3785#issuecomment-3065118310_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
