Suppose I am developing a java library such that if it is added to spring boot application, it automatically configures application context. Say, it adds some properties or beans.
Thus, I am going to use META-INF/spring.factories file with org.springframework.boot.autoconfigure.EnableAutoConfiguration property to let spring-boot bootstrap my configuration classes.
I also want this library to be flexible, so I am going to use such annotations as @ConditionalOnMissingBean or @ConditionalOnClass etc..
I found out that these annotations are coming from org.springframework.boot:spring-boot-autoconfigure library.
This library contains lots of particular autoconfigurations such as elasticsearch, groovy or solr, which I am absolutely sure will not use in my application. Even worse, there are autoconfigurations, such as kafka or jdbc, which will definitely mess into my configurations, so I will need to turn them off manually.
My question is the following. Why can org.springframework.boot:spring-boot-autoconfigure combine such different concepts? On the one hand, it contains reusable annotations, which come handy if you make a starter library. On the other hand, it has partucular autoconfigurations inside which may or may not be needed. I feel I don't understand something here. It seems to me that there can be some kind of violation of Common Reuse Principle. Is there a way to make a starter library with flexible conditionals but not bloatet with unused autoconfigurations from org.springframework.boot:spring-boot-autoconfigure library.?
Sorry if my question sounds somewhat vague, but I really feel like there can be a conceptual misunderstanding on my part.
I see the following solutions, neither of which I like.
Humbly use annotations from
org.springframework.boot:spring-boot-autoconfigureand hope autoconfigurations never step into my application.Copy annotations to my starter library not to depend on unneeded autoconfiguraions from
org.springframework.boot:spring-boot-autoconfigure
