Support SemVer format in Spring Initializr wizard

[snicoll]

The Spring portfolio recently decided to switch to SemVer and CalVer format. This has an impact on the metadata that start.spring.io serves as the format for available bootVersions and the compatibilityRange can change.

For backward compatible reasons, any use of such version format is automatically translated to the documented format of application/vnd.initializr.v2.1+json. However, we need to transition so that STS understands the new format and can apply it. We've published a new metadata version, application/vnd.initializr.v2.2+json that does not perform this translation anymore.

The version infrastructure in the Spring Initializr project showcases the difference and what it takes to handle the new format.

[kdvolder]

Do you have a concrete example of where it makes a difference? I.e. is there, for example, particular dependency in initializer where the data in old and new format looks different? Having a specific example to focus on when implementing and testing it would be very helpful.

Also I'm trying to understand if there is in fact anything we need to do, since, as far as I know STS already uses Osgi library functionality to parse versions and version ranges. So I think it is already capable of handling these things properly.

For example:

https://github.com/spring-projects/spring-ide/blob/master/plugins/org.springframework.ide.eclipse.boot.wizard/src/org/springframework/ide/eclipse/boot/wizard/DependencyTooltipContent.java#L21

Shows we use osgi framework to parse versions / ranges.

And here is an example how it uses it:

https://github.com/spring-projects/spring-ide/blob/master/plugins/org.springframework.ide.eclipse.boot.wizard/src/org/springframework/ide/eclipse/boot/wizard/DependencyTooltipContent.java#L159

and

https://github.com/spring-projects/spring-ide/blob/master/plugins/org.springframework.ide.eclipse.boot/src/org/springframework/ide/eclipse/boot/core/initializr/InitializrServiceSpec.java#L224

Of course, It would be good to make sure this really works properly. And for that it would be nice if there were some concrete examples of metadata you are concerned about specifically. Then we can do some tests with these specific examples and see if everything works as intended, or if some fixes are still needed.

[kdvolder]

From what I can tell so far... this comment in the linked page:

For snapshots, we will use -SNAPSHOT. Note that .BUILD that was present in our previous scheme has been removed.

... was actually causing a bug for us before (as can be seen from special case handling
https://github.com/spring-projects/spring-ide/blob/master/plugins/org.springframework.ide.eclipse.boot/src/org/springframework/ide/eclipse/boot/core/initializr/InitializrServiceSpec.java#L230

Osgi library would misunderstand the proper ordering of build snapshot because 'B' is alphabetically before 'M' or 'RC' and would be considered as 'older' where typically should be treated as newer.

Seems like the new versioning scheme avoids that mistake and maybe we could remove that special case now if we wanted to.

[snicoll]

Hold on please.

The first version format is not going away so nothing should be removed. Both V1 and V2 formats must be supported so:

• You should still be able to parse the format that was served for the past years, there's nothing changing about that (we're still providing Spring Boot 2.1, 2.2 and 2.3 that don't use this new format, please review the blog post in the first link).
• When you consume the new v2.2 metadata, the V2 format for certain dependencies (Spring Boot 2.4+) will also be provided and you should be able to understand it.

Do you have a concrete example of where it makes a difference?

Try to generate a project consuming the v2.2 metadata and you'll get a bunch of warnings

java.lang.IllegalArgumentException: invalid range "[2.0.0.RELEASE,2.4.0-M1)": invalid version "2.4.0-M1": non-numeric "0-M1"
	at org.osgi.framework.VersionRange.parseVersion(VersionRange.java:195)
	at org.osgi.framework.VersionRange.<init>(VersionRange.java:164)
	at org.springframework.ide.eclipse.boot.core.initializr.InitializrServiceSpec$Dependency.isSupportedFor(InitializrServiceSpec.java:227)
	at org.springframework.ide.eclipse.boot.wizard.NewSpringBootWizardModel$5.compute(NewSpringBootWizardModel.java:508)
	at org.springframework.ide.eclipse.boot.wizard.NewSpringBootWizardModel$5.compute(NewSpringBootWizardModel.java:1)
	at org.springsource.ide.eclipse.commons.livexp.core.LiveExpression.refresh(LiveExpression.java:74)
	at org.springsource.ide.eclipse.commons.livexp.core.LiveExpression$1.gotValue(LiveExpression.java:116)
	at org.springsource.ide.eclipse.commons.livexp.core.LiveExpression.addListener(LiveExpression.java:171)
	at org.springsource.ide.eclipse.commons.livexp.core.LiveExpression.dependsOn(LiveExpression.java:119)
	at org.springframework.ide.eclipse.boot.wizard.NewSpringBootWizardModel$5.<init>(NewSpringBootWizardModel.java:502)
	at org.springframework.ide.eclipse.boot.wizard.NewSpringBootWizardModel.createEnablementExp(NewSpringBootWizardModel.java:501)
	at org.springframework.ide.eclipse.boot.wizard.NewSpringBootWizardModel.discoverOptions(NewSpringBootWizardModel.java:491)
	at org.springframework.ide.eclipse.boot.wizard.NewSpringBootWizardModel.<init>(NewSpringBootWizardModel.java:143)
	at org.springframework.ide.eclipse.boot.wizard.NewSpringBootWizardFactoryModel.lambda$0(NewSpringBootWizardFactoryModel.java:28)
	at org.springframework.ide.eclipse.boot.wizard.InitializrFactoryModel$1.compute(InitializrFactoryModel.java:54)
	at org.springsource.ide.eclipse.commons.livexp.core.LiveExpression.refresh(LiveExpression.java:74)
	at org.springsource.ide.eclipse.commons.livexp.core.AsyncLiveExpression.syncRefresh(AsyncLiveExpression.java:125)
	at org.springsource.ide.eclipse.commons.livexp.core.AsyncLiveExpression$1.run(AsyncLiveExpression.java:95)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.IllegalArgumentException: invalid version "2.4.0-M1": non-numeric "0-M1"
	at org.osgi.framework.Version.parseInt(Version.java:169)
	at org.osgi.framework.Version.<init>(Version.java:134)
	at org.osgi.framework.Version.valueOf(Version.java:255)
	at org.osgi.framework.VersionRange.parseVersion(VersionRange.java:193)
	... 18 more
Caused by: java.lang.NumberFormatException: For input string: "0-M1"
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.base/java.lang.Integer.parseInt(Integer.java:652)
	at java.base/java.lang.Integer.parseInt(Integer.java:770)
	at org.osgi.framework.Version.parseInt(Version.java:167)
	... 21 more

The documentation has an updated metadata sample that showcases the V1 and V2 format working together, see a bootVersion with 2.4.0-SNAPSHOT and the compatibility range for org.acme:bur.

[kdvolder]

You should still be able to parse the format that was served for the past years, there's nothing changing about that

Okay good to know. I actually assumed as much.

please review the blog post in the first link

I did and found it a bit unclear as to what has actually changed, hence my question for concrete examples of difference / problems caused by this change.

Thanks for providing the examples now. I will work on switching the wizard over to requesting the 'v2.2' metadata format specifically, and make sure it accepts this format.

I would also like / prefer some guidance as to what kind of timeline you would expect the new format to become 'mandatory'. In the interest of backwards compatibility I think it would be good that, while we do make sure the wizard is ready for this change... we actually do not switch to having the wizard explicitly request the new format until later (in production STS at least). We don't know if people may be using the wizard still with older deployments of initializer and those might break if STS explicitly requests the new format.

Anyhow, that is just my thoughs and I will just go along with what you think is best in this respect. But please be very clear on what you think the next release of STS should do w.r.t. the content type it explicitly requests from the service. Do we request the old format or the new one? And what would be the timeline on changing that?