Following the modularization and restructing in 4.0, we're (not surprisingly) hearing that the role of the starters is now a little confusing. For example:
- it's not clear why some things have starters and others do not
- it's not clear when there is a starter if it should be used or if direct dependencies on one or more of the new modules should be used
For the first of these, the rule in the past has been that we only have a starter if it combines multiple dependencies. We should review the existing starters with this rule in mind as more of them may now be redundant. For example, spring-boot-starter-validation could be replaced with a dependency on spring-boot-validation and not much would have to change for spring-boot-security to be a replacement for spring-boot-starter-security.
For the second of these, I think we'll have to wait and see the outcome of reviewing the existing starters. That should help us to figure out if the starters are:
- purely for backwards compatibility
- still useful for cases when multiple dependencies are being combined
- something else
Comment From: sdeleuze
For the sake of simplicity, consistency and reducing the cognitive load, I think my personal preference would be to keep starters purely for backwards compatibility, to allow simple guidelines like "if you are still using starters with Spring Boot 4, you should probably evolve it".
That applies to Spring Boot applications, but I am also thinking about the ecosystem of custom starters where that would allow to track the adoption of some potential upcoming guidelines that will embrace the modularisation and provide related guidance for the ecosystem. Would allow to say "migrate your starters + autoconfiguration to proper Spring Boot 4 ready modules". If you blur the line, that will be harder to differentiate legacy starters that should be migrated from still relevant one. If multiple dependencies need to be combined, and if as I suspect they are not hugely common, maybe you can just introduce proper non starter modules, or just recommend adding mutiple dependencies.
start.spring.io would be updated to use only non starters dependencies when using Spring Boot 4, and starters could be entirely removed in Spring Boot 5.
Comment From: philwebb
We don't always have a module that fully represents a current starter. For example, the web starter is Tomcat + MVC + Jackson. We certainly have the opportunity to revisit that, but I think the concept of "giving me the things I'm likely to start a typical app" is pretty useful. We probably need an extensive review of the existing starters and why they exist. It's going to get pretty confusing pretty quickly if folks need to guess when to use one or another.