ppkarwasz commented on issue #3771:
URL:
https://github.com/apache/logging-log4j2/issues/3771#issuecomment-3311281590
Hi @ctubbsii, thanks for clarifying your setup.
> I think I saw warnings with the unused `-A` option on the multi-module
project (even with `-Xlint:-processing`, though that might need further
debugging), and also when we didn't set it. Both caused `maven-compiler-plugin`
to exit and fail our build. So, setting it didn't work, and neither did leaving
it unset.
You’re right:
* If you **do** provide the `-A` options but there’s no `@Plugin` in the
sources, javac emits a warning about unrecognized processor options. That
diagnostic does **not** come from the `-Xlint` framework, so
`-Xlint:-processing` won’t silence it.
* If you **don’t** provide the `-A` options and there *are* `@Plugin`
annotations, then the `GraalVmProcessor` itself emits a warning.
To avoid either case, the safest setup is to add the `-A` options **only**
in the module(s) that actually declare Log4j plugins, and to scope them to the
appropriate execution (`default-compile` for `main`, `default-testCompile` for
`test`):
```xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<configuration>
<compilerArgs combine.children="append">
<arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
<arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
</compilerArgs>
</configuration>
</execution>
</executions>
</plugin>
```
> I understand Java doesn't have a way to exclude a processor from its
autodiscovery process, but setting a system property that the processor
understands as "I should exit successfully without doing any work" would be
quite convenient …
That’s a fair request. The challenge is that adding a new Log4j-specific
“skip” property would increase the number of moving parts people need to check
when annotation processing doesn’t run. The compiler already supports the
inverse (explicitly enumerating processors to include), so introducing an extra
opt-out switch can introduce unnecessary complexity.
If we tried to use `-A` options as a “disable” flag, we’d still face the
same problem: unused `-A` options trigger warnings in modules where no
annotations are processed. And since javac doesn’t accept `-D` system
properties as processor options, that path isn’t really available either.
What we *can* do, however, is reconsider the severity: we could lower the
message from `WARNING` to `NOTE`. That way the processor still runs correctly,
GraalVM native-image users still get the metadata, and the only trade-off of
not setting the options is a randomly-named JSON resource in the JAR. @vy, any
thoughts?
### Side note
I really appreciate teams that run with “zero warnings” policies. Out of
curiosity, do you also enforce this philosophy with tools like Error Prone or
SpotBugs alongside javac’s linter? In my experience, the biggest value comes
when that strictness is applied consistently across static analysis, not only
linter warnings.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
