spring-boot - 有什么理由不将小型 spring-boot 启动器与自动配置放在一起？

Question

spring-boot 使用“starters”来定义项目可能包含的一组库依赖项。这个maven模块，Jersey的starter，例如:
https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters/spring-boot-starter-jersey

spring-boot 使用自动配置来实例化和配置启动模块中的类。 Jersey 的自动配置:
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jersey/JerseyAutoConfiguration.java

是否有任何理由不将新的第 3 方/私有(private)启动器与自动配置放在同一模块中，而不是像上面的示例那样分成不同的模块？

Answer 1

这是一个很好的问题，我们在 Spring Boot 工程团队中一直争论不休，因此没有正确的答案。相关讨论要点:

• spring-boot-autoconfigure 最初是一个相当小的库(1.0 之前)。现在它已经发展到了它的 pom 长得离谱的程度(几乎所有东西都是可选的)。

• 启动器执行不止一种功能，从某种意义上说，它们可以用于激活自动配置位，而且(更重要的是) ，它们是一组固执己见、精心策划的依赖项，可能(而且通常确实)超出了激活某些自动配置所需的最低限度。这基本上就是 Marten 的观点。

• Spring Boot .NEXT(目前为 1.3)很可能将 spring-boot-autoconfigure 分解为多个模块(例如，可能有一个用于 jetty，或者可能有一个用于 servlet 容器，或者其他一些模块)。

当分拆发生时，我们可能会看到一些启动器变得过时(谁知道这一点)，但我怀疑它们仍然存在。 Spring Cloud 有很多未捆绑的自动配置，但仍然有启动器，例如。

对于小型第三方库，我认为没有理由不将启动器和自动配置放在同一位置。我认为允许这个线程出现在 stackoverflow 上的唯一理由是是否可以重新措辞以使问题更加明显。