By default, the compiler attempts to discover annotation processors from the classpath. This can have side effect on code that is generated ahead of time.
Adding -proc:none in the Maven and Gradle integration could be on way of making sure these don't run.
See also https://github.com/spring-projects/spring-framework/issues/30824 which now annotates every generated class which should trigger a warning if AP is active and no processor claimed it (which is likely to happen).
Comment From: wilkinsona
We may not need to do anything for Gradle builds. Gradle should ignore annotation processors on the compile classpath and only use those declared in the aotAnnotationProcessor configuration. If a user's made such a declaration I think we should honour it as it's very unlikely that it has been done accidentally.
Comment From: philwebb
@snicoll Do you have a sample project available that produces the warning?
Comment From: snicoll
Nope, sorry. I had the warning in framework tests using TestCompiler as it used to detects annotation processors from the classpath. I suspect that maybe the warnings from the compiler in the Maven plugin may not be redirected to the logs? I've tried to reproduce with a vanilla app and the context indexer and that didn't work. But I can see now that's because it claims all annotations. I'll have to dig a bit more.
Regardless, the issue is not really about the warning, but about the fact that, if I am not mistaken, AP (at least with Maven) are invoked by the AOT compilation run and shouldn't.
Comment From: philwebb
Regardless, the issue is not really about the warning, but about the fact that, if I am not mistaken, AP (at least with Maven) are invoked by the AOT compilation run and shouldn't.
Are we 100% sure that annotation processors should not run during the AOT compilation phase? If I user has something like Lombok or a null checker, won't they need to run the annotation processor?
Comment From: philwebb
After some more discussion with @snicoll things have become a bit clearer. We're not looking to disable annotation processing of user code, rather we'd want to make a change to this part of ProcessAotMojo so that annotation processors are not invoked on generated code.
Comment From: wilkinsona
We don't have complete control over the code that's generated. It's possible that someone has written a custom code generation contribution that relies on annotation processing. If we made this change, it would break them so I wonder if we'd also need to add a way to reverse it.