@ProjectGenerationConfiguration classes share two traits of auto-configuration: we register them in spring.factories and they should not be detected by component scan.
While it is expected that auto-configuration must not sit in the app's target package space, customizers and contributors of the project definitely make sense there. The current arrangement is sub-optimal as we have to do something to prevent those classes to be picked up and added in the main context. If such customizer defines a project condition this will even lead the context to fail as it is likely that no ResolvedProjectDescriptor bean is present.
We could register an exclude filter the same way we did for auto-configurations but it would be very nice if we had a way to transparently handle this problem. @InitializrApplication comes to mind but I am not fond of the idea.
@ProjectGenerationConfigurationclasses share two traits of auto-configuration: we register them inspring.factoriesand they should not be detected by component scan.While it is expected that auto-configuration must not sit in the app's target package space, customizers and contributors of the project definitely make sense there. The current arrangement is sub-optimal as we have to do something to prevent those classes to be picked up and added in the main context. If such customizer defines a project condition this will even lead the context to fail as it is likely that no
ResolvedProjectDescriptorbean is present.We could register an exclude filter the same way we did for auto-configurations but it would be very nice if we had a way to transparently handle this problem.
@InitializrApplicationcomes to mind but I am not fond of the idea.