Initializr metadata v3

[snicoll]

The current production version for all remote clients is v2.1. There are a number of changes that are required to improve the metadata model and to limit the disruption for remote clients, I'd like we propose brainstorming on a version 3 of this model.

v2.1 and v3 should be served at the same time with v2.1 being exactly as it is today. As long as the proper accept header is issued, existing clients shouldn't see the difference. We also need some metrics to measure the rate at which new clients pick this up.

This issue will be edited with the topics we'd like to include in this new major version. Current proposals include:

• Rename bootVersions to platformVersions
• Rename javaVersions to jvmVersions (see Rename javaVersion to jvmVersion #773)
• Rename versionRange to compatibilityRange (see Rename versionRange attribute to compatibilityRange #968)
• Remove the /dependencies endpoint
• Properties mapping to improve link handling (Provide custom properties mapping in the metadata #775)
• Constraints jvm version based on the platform version (see Disable or hide Java 8 and 11 options for Spring Boot 3.x start.spring.io#910)

[joshlong]

hi - could this perhaps be a vehicle by which to introduce other, non-dependency, checkboxes to the Spring Initializr?

for example: imagine a checkbox for AppCDS, Leyden, the virtual threads support (spring.threads.virtual.enabled=true, or a .sdkmanrc file or .jenv file, or other cool infrastructure features like that? We sort of do this with GraalVM, except that actually configures a dependency. A lot of these other things would surface features in configuration or add new files. It would make visible to the user some of the amazing things Spring can do for you and let them know it's a choice they could have.

[mhalbritter]

@joshlong We're starting by collecting use cases for non-dependency checkboxes and then see if and when we implement something like this. I've opened spring-io/start.spring.io#1679 for that.