GitHub user ppkarwasz added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options
> Due to our steps to keep deprecated code out of the codebase, this warning — > for something we neither use nor care about — is breaking the build. It > doesn't make sense to have to provide useless configuration in *N* different > builds just to silence it. I completely understand the frustration of a build breaking due to what seems like irrelevant configuration. But since you're clearly invested in keeping your codebase clean and free of deprecated elements, this might actually be a good opportunity to evaluate a few things: ### 1. **Why is `log4j-core` on your compile classpath?** `log4j-core` is the standard implementation of the Log4j API and is typically only needed at **runtime**. However, we often see it added with `compile` scope — even when it's not strictly necessary. Unless you're writing custom Log4j plugins or manipulating internal APIs (which we generally advise against), `log4j-core` should be declared with **`runtime` scope**. > 📘 See: [Log4j Manual – Installing a Logging > Implementation](https://logging.apache.org/log4j/2.x/manual/installation.html#impl) If you're not developing Log4j plugins, does `log4j-core` really need to be on your compile classpath? Some projects include `log4j-core` to perform **programmatic** logging configuration at runtime. While that may seem reasonable, it typically creates tight coupling to a specific logging implementation, which can make it difficult for downstream users to swap in a different backend (e.g., JUL, Logback, etc.). To address this limitation, we're open to introducing a **backend-agnostic API** for safely modifying logger behavior at runtime. A preliminary proposal is available in the [`logging-admin`](https://github.com/apache/logging-admin) project, and we're actively looking for real-world use cases to help shape the design. If your project depends on this kind of programmatic configuration, we’d really appreciate your input. ### 2. **Do you really need custom Log4j plugins in tests?** We’ve noticed several users (including some in this discussion) define custom Log4j plugins for unit tests — but we rarely receive feature requests to improve the `log4j-core-test` module, which provides ready-made test fixtures like `ListAppender`. If you're writing custom plugins purely to verify logging behavior, could you share what `ListAppender` is missing for you? The last feedback we received on this was back in 2022 ([log4j-user thread](https://lists.apache.org/thread/3n9xqc132pm49w3m67zm6wnjfw6yphkq)). We’d genuinely welcome a discussion or issue detailing your test needs — it's the kind of input that helps shape better tooling for everyone. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13768173 ---- This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
