Investigate splitting configuration and auto-configuration

[philwebb]

Currently spring-boot-autoconfigure contains quite a bit of code that would also be useful if manually configuring and application. For example, we have many *Properties classes and functions that map them. We should investigate if splitting out a spring-boot-configure module would be worthwhile.

This new module would be particularly useful for projects like https://github.com/spring-projects/spring-fu since it would allow them to call well designed public configuration APIs, rather than trying to work with the existing auto-configuration classes which were never really designed to be called directly.

[wilkinsona]

The configure in the name of the module has been niggling me a little bit as the module won't configure anything in the @Configuration sense. Given that we've described Boot in the past as being convention-over-configuration, the way that I've now started thinking about it is that the new module will encapsulate Spring Boot's conventions and spring-boot-autoconfigure will become the module that automatically configures those conventions. That led me to wonder if the new modules should be called spring-boot-convention or spring-boot-conventions rather than spring-boot-configure. Convention could be used in class names for things like WebMvcConventions, AmqpConventions, etc and avoid overloading Configuration.

[snicoll]

I like the WebMvcConventions part quite a lot!

[wilkinsona]

We don't think this is worth pursuing at this time. Splitting the code in this manner will roughly double the number of classes that are involved in auto-configuring a component. The costs of this (increased memory usage, slower startup time) will outweigh the benefits.