Changes break STS Gradle import about initializr HOT 8 CLOSED

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.

from initializr.

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".

from initializr.

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.

from initializr.

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.

from initializr.

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

from initializr.

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.

from initializr.

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.

from initializr.

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.

from initializr.