Currently, the Spring Boot ecosystem makes heavy usage of conditional bean creation with @CondtionalOnXXX annotations. Some of them evaluate environment properties and favor the usage of application.properties.

The spring-boot-configuration-processor already offers a great way to annotate properties with metadata to support IDE features for documentation, validation and auto-complete. Unfortunately, the @CondtionalOnXXX annotation which involve simple environment checks are not processed by the ConfigurationMetadataAnnotationProcessor and hence no metadata is produced automatically.

I would love to see support for at least trivial cases such as * @ConditionalOnEnabledHealthIndicator * @ConditionalOnProperty(value = "xxx.enabled", matchIfMissing = true)

Has this been already considered? I would be willing to provide a PR if the maintainers deem it worthy enough a feature

Comment From: snicoll

Has this been already considered?

Annotation processors react to the presence of certain annotations a processor declares it supports. Once they are present on an element, the compiler invokes the annotation processor with the annotated element. With ConditionalOnProperty it's ok, except you get a property with no meaningful context. The main goal of the metadata is to provide assistance to the user and I don't really see how we could extract a meaningful description. Enabled properties are not the only ones used with this annotation so if you had something a bit more involved, the automatic generation may go in the way.

Then the actual big problem is meta-annotations. Annotation processors don't support them. To be consistent, we'd need to support cases such as the @ConditionalOnEnabledHealthIndicator you've mentioned. To be able to do that, we'd need to switch to an annotation processor that reacts to all annotations and start analyzing them. I've recently declined an issue along the same lines.

Having said that and since you offered a PR, is there anything that I've missed here?

Comment From: aegliv

Thanks for the quick response! I have no experience with preprocessors, I only did a quick POC in bash. But I assumed you would have the full power of static code analysis at your disposal - hence my hope that you would know the surrounding class structure. In case of the @ConditionalOnProperty("xxx.enabled", matchIfMissing=true) case, the metadata information is single purpose: Set the property to false to disable the Bean. If the annotation is on a method the bean name is the return type of the method, on the class level it would be the class itself. I don't see a reason to customize this information further.

The HealthIndicator is even better as it is designed for only one purpose.If meta-annotation processing is not possible, than my script might already be the best solution?

Comment From: snicoll

I don't see a reason to customize this information further.

You're missing the most important one, the description. It explains what the property does and doing this the way you request would mean we'd lose that. You also ignore my comment about the fact that this condition can be used by something else than .enabled.

Thanks for the feedback but all the points that I've raised are still valid so we won't pursue this.