Split auto-configuration out into several smaller, more focused modules

[rupert-madden-abbott]

At the moment, various templating libraries, are integrated with Spring in the following way:

• they have auto-configuration inside spring-boot-autoconfigure which integrates them as renderers for HTTP responses
• they activate based on the presence of that templating library on the classpath
• they have a starter that adds the necessary libraries onto the classpath
• they have a "disabled" property that allows an application to disable the HTTP integration

The problem is that templating libraries can be pulled in for reasons other than for templating HTTP views. For example, I imagine a very common use case would be for templating emails. When this is done, one must remember to also set the disabled property or else warnings can be shown at startup and unexpected problems can occur like this one.

One way I can see that this behavior could be improved is by moving the auto-configuration for these libraries out of spring-boot-autoconfigure and into the starters instead. So spring-boot-starter-mustache would also pull in the mustache auto-configuration. Perhaps the starter should also make it more clear that it is supposed to be for web templating only e.g. spring-boot-starter-web-mustache. If this were done then:

• The disabled properties would be come redundant and could be removed
• Users who wanted to use these libraries in the web tier would just need to pull in the starter, as they are likely already doing
• Users who do not want to use these libraries in the web tier would not use the starter, and would either use the underlying library directly, or via some other third party starter library

This also means that if the templating library arrives on the classpath as a transitive dependency, the application author no longer needs to explicitly disable the auto-configuration integrating it into the web tier.

[philwebb]

We've actually discussed this idea many times on the team but not yet had a good opportunity to take it on. Ideally we'd like to keep the starters as they and instead create more granular auto-configuration jars on which the starters could depend on.

Unfortunately, it's quite a big job to split up auto-configuration.