Support Initializr Metadata v2.2

[snicoll]

The Spring team has recently decided to switch their version scheme to SemVer format. This had an unexpected result for remote clients of start.spring.io as the format of the Spring Boot versions (bootVersion attribute) and the compatibilityRange in some dependencies can have an unexpected format.

We figured it out and translated those formats to the original format on the fly. This fixes the problem but is not ideal as remote clients can have a version pattern that actually does not exist. We've introduced a new metadata version, v2.2 that does not do that translation. Going forward, the original format and the new SemVer format can coexist. Ultimately, only the SemVer will remain once the Spring Boot releases using the original format go EOL.

In order to consume that format, the client needs to understand semVer, in particular for version ranges. I don't know if this plugin is impacted by if it is, VersionHelper should be impacted.

For some time, both v2.1 and v2.2 should be supported. start.spring.io supports both obviously but the user may point to a custom instance that hasn't been upgraded yet. You could use content negotiation to mark a preference for 2.2 and consume 2.1 if it's not available, something like

Accept: application/vnd.initializr.v2.2+json,application/vnd.initializr.v2.1+json;q=0.9

(the default factor is 1.0). I believe this should be done in ServiceManager. The actual version can be checked in the Content-Type attribute of the reply although it shouldn't matter to you once you understand both version formats.

Let me know if something isn't clear. Thanks a lot for your hard work on this plugin!

[Eskibear]

It's good know that Spring also switches to SemVer! I just compared the responses, finding versionRange and bootVersion.id affected for the moment. So, VersionHelper mentioned above won't work well for v2.2.

v2.1

"versionRange": "[2.2.0.RELEASE,2.4.0.M1)"
"id": "2.4.0.BUILD-SNAPSHOT"

v2.2

"versionRange": "[2.2.0.RELEASE,2.4.0-M1)"
"id": "2.4.0-SNAPSHOT"

Just to confirm that, before we support v2.2, VersionHelper is not broken because of the on-the-fly translation. So nothing will be broken, as the versionRange is only used to validate availability of the dependencies. Is that right?

Agreed with the proposal you mentioned above, and I'll enhance VersionHelper to support both formats. (BTW I just feel it would take a long time to completely retire the old version format.)

[snicoll]

You're not broken at the moment as v2.1 provides version in a format that you already understand.

And yes, both formats must be supported to be compliant with v2.2.

[Eskibear]

@snicoll
I've made some changes per discussion above. When playing with v2.2 metadata, I find the dependencies endpoint seems not working (404). Below are my requests.

===Request 1===
GET / HTTP/1.1
Host: start.spring.io
Accept: application/vnd.initializr.v2.2+json
Cache-Control: no-cache

===Response 1===
content below:
{
    "_links": {
        ...
        "dependencies": {
            "href": "https://start.spring.io/dependencies{?bootVersion}",
            "templated": true
        }
    },
...


===Request 2===
GET /dependencies?bootVersion=2.3.2 HTTP/1.1
Host: start.spring.io
Accept: application/vnd.initializr.v2.2+json
Cache-Control: no-cache

===Response 2===
HTTP/1.1 404 
Date: Wed, 12 Aug 2020 07:46:11 GMT
Content-Length: 0
Connection: close
Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Via: 1.1 google
CF-Cache-Status: DYNAMIC
cf-request-id: 04833b4d630000cc28e58dc200000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Strict-Transport-Security: max-age=15552000; includeSubDomains
Server: cloudflare
CF-RAY: 5c1894c23b77cc28-SIN

Do you have any idea about it?

[snicoll]

@Eskibear thanks for the feedback. This is an oversight on our end, partially due to the fact this endpoint is deprecated and will be removed in v3 (see spring-io/initializr#958).

I've created spring-io/initializr#1115 to let you get access to the content with v2.2 and I understand using this endpoint is some existing code you've received but this feature will be removed in a near future so please remove all use of this endpoint as soon as possible.

Also, if you use the Accept header that I've suggested, this should allow you to make progress, i.e.

Accept: application/vnd.initializr.v2.2+json,application/vnd.initializr.v2.1+json;q=0.9

[Eskibear]

Thank you for the information. The dependencies endpoint does block our current implementation for "Edit starters" (allow add/remove). But we'll follow STS's new implementation and replace it with "Add starters", and all use of this endpoint will also be removed at that time.

As for the Accept header, we've already adopted the one you mentioned above, see

vscode-spring-initializr/src/model/ServiceManager.ts

Lines 9 to 13 in 2afe19f

	/**
	* Prefer v2.2 and fallback to v2.1
	* See: https:/microsoft/vscode-spring-initializr/issues/138
	*/
	const METADATA_HEADERS = { Accept: "application/vnd.initializr.v2.2+json,application/vnd.initializr.v2.1+json;q=0.9" };

[snicoll]

@Eskibear so you're not blocked then are you? I am a bit confused as the example above is using a different accept header. And great to hear you're moving away from that undocumented dependencies endpoint.

[snicoll]

@Eskibear start.spring.io has been updated to handle 2.2 only for consistency, although you shouldn't be using that but rather the Accept header that was shared previously. Thanks for letting us know.

[Eskibear]

Let me be clear, basically we have two actions:

• create project. It's not blocked.

• edit starters. It's acutally not blocked now and works well if I use Accept: application/vnd.initializr.v2.2+json,application/vnd.initializr.v2.1+json;q=0.9. I just happened to find it doesn't work for application/vnd.initializr.v2.2+json before and that made me a little bit confused. (Because current implementation is using dependencies endpoint to query compatible starters and corresponding information like artifact id, group id, bom, etc..)

start.spring.io has been updated to handle 2.2 only for consistency

This explains the behavior, and now it's unblocked. Thanks for the quick update.

[Eskibear]

supported in v0.5.0