Spring-boot allows to configure a custom BeanNameGenerator. This custom BeanNameGenerator is not picked up by spring-data, but rather the default implementation is still gonna being used. This leads to unexpected bean names at best, or subtile errors at worst, especially with spring-boot 2.0.x versions, which allow to override bean definitions by default.
I am not completely sure, if that's a bug or a feature, at least it is somehow unexpected. When I configure a custom BeanNameGenerator for spring, I would expect it to be used not only in a subset of spring-projects.
Spring Data repository naming uses a slightly different variant of the BeanNameGenerator as we have advanced needs to derive bean names based on our configuration. However, we use the standard AnnotationBeanNameGenerator as fallback. It doesn't look like there was API for us to use to lookup the BeanNameGenerator set on the ApplicationContext yet.
Interestingly org.springframework.context.annotation.ConfigurationClassPostProcessor also uses a custom BeanNameGenerator for registering any @Configuration beans, also using FQCN instead of simple ones. I can just guess why, but there have been probably a lot of bean name clashes with config classes.
Generating bean names by using simple class names was in the past probably a good way to strengthen backward compatibility with applications, which still use name-based injection. As (qualified) type-based injection is probably more used these days, this kind of compatibility might not be necessary any more.
We need Spring Framework tweaked to expose the BeanNameGenerator used for configuration class scanning forwarded into ImportBeanDefinitionRegistrars. Jürgen's already on it and we'll be upgrading to the refined API for Moore
There's a draft implementation available via 2.2.0.DATACMNS-1497-SNAPSHOT of the spring-data-commons artifact. It will require a Spring Boot application to use e.g. @EnableJpaRepositories explicitly as Boot doesn't forward the BeanNameGenerator yet through it's intermediate ImportBeanDefinitionRegistrar.
The fix contains a rather brittle check for the default BeanNameGenerator handed down as we'd like to stick to the AnnotationBeanNameGenerator by default and the default one tweaking the bean name generation to use fully qualified class names which would render the repository beans being named differently than any other scanned bean definition. I'll reach out to Jürgen if we can make this less brittle by exposing the default one as constant
My contract has ended, so I can't proof this to be functional for the original project, but according to a dummy project, custom BeanNameGenerators are never forwarded from AbstractRepositoryConfigurationSourceSupport.
with overridden: spring-data-commons:2.2.0.DATACMNS-1509-SNAPSHOT