Reorganizing all starters

[oliemansm]

Over the years the number of starters in this project has grown significantly. Even though they can be categorized in certain groups, the way they act can differ within the category. I'd like to get some feedback on the proposal outlined in this discussion to define a new downsized and improved set of starters.

Starter	Category	Description
altair-spring-boot-starter	GraphQL IDE	Exposes Altair
graphiql-spring-boot-starter	GraphQL IDE	Exposes GraphiQL
graphql-kickstart-spring-boot-starter-graphql-annotations	GraphQL Server	Servlet server using annotations
graphql-kickstart-spring-boot-starter-tools	GraphQL Tools	Builds schema from SDL and classes
graphql-kickstart-spring-boot-starter-webflux	GraphQL Server	Reactive server requiring you to manually add tools or annotations dependency
graphql-spring-boot-starter	GraphQL Server	Servlet server using graphql tools
graphql-spring-boot-starter-test	Test	Test utilities, but can only support Servlet at the moment
playground-spring-boot-starter	GraphQL IDE	Exposes Playground
voyager-spring-boot-starter	GraphQL IDE	Exposes Voyager

Proposed reorganization

Deprecate all starters, and create two new starters to hold all functionality.

graphql-kickstart-spring-boot-starter

Will support every use case the current starters support except the testing utilities. It will no longer pull in Spring webflux or webmvc automatically, but instead will require you to do that manually. It will check which web environment type has been loaded and configure that automatically. In case both are available for some reason you can specify which one should be used with a property.

Two possible solutions for defining which technology to use to map the schema: annotation or graphql tools.

1. No longer pull them in automatically, but instead require to manually add the dependency. Downside of this option is that there are often incompatibility issues and users try to use the wrong version of tools with the starter for example. Because of this we've been instructing users to rely on the starter to pull in the correct version instead for years, and this solution would change that position with all those potential problems again coming with it.
2. Pull them in automatically, but require the user to specify which one to use using a property. Upside is it'll always pull in the compatible versions. Downside is it pulls in more dependencies than you're actually going to need.

The starter will also contain support for all of the above IDEs instead of using all those separate starters. It'll just be a matter of enabling them through properties.

graphql-kickstart-spring-boot-starter-test

Rename of the current test starter, and adding support for webflux too. Spring Boot naming convention for custom starters is to have your library name and then end with "spring-boot-starter". Not sure what the conventions are for test starters like this one.

[vojtapol]

I am all for this change. I think it would be much more maintainable to have only few starters and enable/disable features by properties. Having a separate GraphiQL and Voyager starter for example is a bit wasteful.

[setchy]

I too am all for this change and agree with @vojtapol feedback - using properties to enable/disable the assortment of tools would be ace.

Could also be a good time to re-document all the available application.properties values the framework supports

[cforce]

Is that done already?