Automatically exclude the annotation processors we know about

[snicoll]

The Spring ecosystem has a number of annotation processors that are usually added as an optional dependency to the Maven build. While the maven-compiler-plugin has a way to declare them in plugin configuration for quite some time, this requires the version to be specified which is quite annoying. Not all IDEs pick up this new way of defining the annotation processor.

Maybe we could improve the Spring Boot Maven plugin to exclude such well-known annotation processors as they are useless at runtime. See #22000

[wilkinsona]

We've taken care of this for Spring Boot's annotation processors in this commit. Was that all that you had in mind, @snicoll, or did you want to cover annotation processors from other projects too?

[snicoll]

@wilkinsona I am not sure. Maybe the context-indexer in framework but we can't really declare that property in the manifest there.

[wilkinsona]

I wonder if there any modules that are used as an annotation processor and at runtime? If not, we could exclude based on the presence of META-INF/services/javax.annotation.processing.Processor.

There’s some risk there and we’re really working around a limitation of Maven. I’m not sure that risk is worth it. We could offer a config option to turn off the exclusion but I’m not sure that’s worth it either. I’m tempted to close this one as I think what we’ve done thus far strikes a reasonable balance.

[filiphr]

I've be following this issue for a while, since I was interested in this functionality and would like to give my 2 cents.

I wonder if there any modules that are used as an annotation processor and at runtime? If not, we could exclude based on the presence of META-INF/services/javax.annotation.processing.Processor.

This is actually not a good idea. In an ideal world every annotation processor will provide 2 jars, one where the annotations are (runtime needed dependencies) and another one for the compile time dependencies. As an example Lombok is one such processor, where you only have one dependency for everything.

There’s some risk there and we’re really working around a limitation of Maven.

Why a limitation of Maven? The maven-compiler-plugin has the annotationProcessorPaths which are similar to the Gradle annotationProcessor. Long time ago I raised #10645, which was meant to provide Project templates which are compatible with that. I just checked and start.spring.io does use annotationProcessor for annotation processors in the generated project.

[wilkinsona]

This is actually not a good idea

That's why I was wondering if there are any annotation process modules that are needed at compile time and at runtime.

As an example Lombok is one such processor, where you only have one dependency for everything

I don't think Lombok is an example of this. AFAIK, Lombok isn't required at runtime.

Why a limitation of Maven?

That's covered in the opening description:

While the maven-compiler-plugin has a way to declare them in plugin configuration for quite some time, this requires the version to be specified which is quite annoying. Not all IDEs pick up this new way of defining the annotation processor.

[snicoll]

Yeah I agree Andy. Excluding them based on the presence of the file is going too far and I am ok to close this one.