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

Comment From: 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?

Comment From: snicoll

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

Comment From: 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.

Comment From: 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.

Comment From: 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.

Comment From: 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.

Comment From: filiphr

That's covered in the opening description:

Sorry I missed the version part. Thanks for the explanation and understanding