A typical @Configuration-annotated bean include a org.springframework.context.annotation.ConfigurationClassPostProcessor.configurationClass attribute in generated code. This attribute is useless at runtime and should not be contributed.
In Spring Native, we took the decision of not writing those attributes and that didn't seem to matter so I don't know how much of those attributes are required.
cc @philwebb
Comment From: philwebb
If we want to remove all attributes entirely we can drop the BeanDefinitionPropertiesCodeGenerator.addAttributes method. Otherwise I guess we need some filter strategy so that the ConfigurationClassPostProcessor can contribute a filter that removes just those attributes.
Comment From: snicoll
Another option would be to find a way to opt-in for certain attributes. I think that keeping the feature and letting him custom implementations drive what they need is interesting.
I am not too sure if we need to exclude an attribute or include a specific attribute (with, perhaps a list of well-known ones we want to include/exclude). In Spring Native we don't use this at all and it's been going ok so far but I am sure we'll hit a problem at some point.
Comment From: snicoll
Moving to M6 as such an optimization of code generation is not a blocker for M5, even if it would have been nice to finalize this part of the API.
Comment From: snicoll
We don't really know what is mandatory and what isn't. It would be nice to make a decision so that teams can test their integration based on what we intend to do for 6.0
Comment From: snicoll
We've decided to stop writing those attributes and get feedback on actual use of the attributes, if any. Based on that we can reconsider our support before GA.