Changes break STS Gradle import

[kdvolder]

This commit is responsible 8f1ce31

For causing this issue:
https://issuetracker.springsource.com/browse/STS-3944

Please don't change the names of the 'type' options. These names mean specific things to the STS import wizard (i.e. what type of import strategy needs to be used to import particular zip file into the IDE).

[dsyer]

Would you be able to adapt STS to use a different field for that, or to parse the id (that's what the "spring init" command does)? If not then I guess we should revert this change.

For the record, it was the "id" (not the "name") field that changed.

[kdvolder]

I could change STS to handle this new version, but that change will only go live on the next release of STS. And it will remain broken in anything <= STS 3.6.1 even if it is fixed in the next release.

So the change should be reverted ASAP (as this will instantly fix the issue :-)

Also FYI, the problem is not that STS doesn't know things have changed. STS knows the new id values. The problem is that STS doesn't know that these new id values mean. So it sees them and ignores them because it "doesn't know how to import such a thing".

[kdvolder]

For the record, it was the "id" (not the "name") field that changed.

Right, in fact changes to the name would not have been a problem.

[snicoll]

The production instance has been updated with the previous ids.

I am not happy I had to revert #39 because the current IDs are quite bad. Kris please provide concrete options that would allow me to restore these.

Right now, the type is something very generic and I like to keep it that way eventually. As you can see, I used some convention in the id that allows you to detect the build system and the kind of artifact it produces. We could add that to the json output (something like build: maven & result:project instead of maven-project) but then the type would be too structured IMO.

I think it nice to have some convention on the ID: that way, STS can drop the things it does not understand.

[kdvolder]

I agree the new ids are better (meanigful, logical etc). We can make newer versions of STS recognize either the old and new ids as synonyms and then a few versions down the road we can phase out the old-ids in the webapp.

Raised a issue targetted for next STS release: https://issuetracker.springsource.com/browse/STS-3948

[snicoll]

It would be better if you start consuming the JSON instead of parsing the legacy HTML. If we want to phase out that structure that is there only for STS, that's what we should do.

[kdvolder]

It would be better if you start consuming the JSON instead of parsing the legacy HTML.

The issue of the ids and whether or not STS consumes JSON<->html are really independent problems. I.e. the id problem would have existed even if STS was consuming the JSON.

But I agree fasing out the html parsing is a good idea. I'll take a look at that at the same time as I look at STS-3948.

Note however that turning off the legacy html completely is a much bigger deal than only taking out the old ids. The id switch just makes the 'import as gradle' option disapear from old STSs. Stopping to provide the html completely means the wizard won't work at all.

[kdvolder]

Just FYI. I have resolved STS-3948. So next version of STS should be happy to consume new or old ids.

As I didn't yet have time to delve into replacing html parser I've raised a new issue for that. https://issuetracker.springsource.com/browse/STS-3950

Will try to get to it for the next release.