Support for meta annotations in AutoConfigureAnnotationProcessor

[filiphr]

I've been looking in to using the autoconfigure-processor for our auto configuration. However, I noticed that it does not work when the @ConditionalOnClass annotations are given through a meta annotation.

In our projects we have something like:

@ConditionalOnClass(name = {
    "com.example.Class1",
    "com.example.Class2"
})
@ConditionalOnProperty(prefix = "com.example", name = "enabled", havingValue = "true", matchIfMissing = true)
public @interface ConditionalOnOurMeta {

}

If you are interested in such functionality I can have a look into the AutoConfigureAnnotationProcessor.

[mbhave]

This sounds like a valid use-case to me but I'm not sure if there is an easy way to trigger the annotation processor based on the meta-annotation. Let's see what the rest of the team thinks.

[filiphr]

Just FYI the annotation processor is triggered for classes with @Configuration. Which means that it would be really easy to check all annotations of those classes and extract the meta @ConditionalOnClass. We can make the assumption that all auto configurations are annotated with @Configuration (I think all Spring Boot auto configurations are already annotated)

[snicoll]

Which means that it would be really easy

I am not so sure about that. If we start supporting meta-annotations then you need to start supporting the full story with @AliasFor and the like. The model in the annotation processor is not the usual reflection model so that algorithm needs to be reimplemented with that API.

Perhaps you had a different idea in mind?

[filiphr]

My initial idea was to start with the most basic meta annotation. i.e. no @AliasFor. More something like in the example I provided.

I don't see why someone would create a new meta annotation with @AliasFor for @ConditionalOnClass. If you need to do that, then why not just use @ConditionalOnClass directly

[snicoll]

I just meant to say you can't really say you support meta-annotations if you support half of the story. And supporting the full story may not be that easy as you seems to indicate it is.

I am not against supporting it for the record, just cautious about side effects before you start spending time on a PR. This issue is flagged for team attention so we'll get more feedback soon.

[filiphr]

You are completely right. For me it was important to start this discussion, as I think that it would benefit others as well. Due to the way we have our auto configuration structured, it would definitely help us.

Honestly, I don't foresee a big issue with the @AliasFor support as well. The annotation processor is quite powerful and it we can easily inspect it.

I am curious about the feedback from the team. I had a better look at the current implementation and I am confident that it won't be too difficult to implement something like this.

[snicoll]

We've discussed this at the team call today and we're not keen to bring that complexity in the annotation processor for something we don't have a use case for at the moment. It's an optimization and we'll fall back to regular lookup for the use cases we don't support.