-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes break STS Gradle import #42
Comments
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. |
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". |
Right, in fact changes to the name would not have been a problem. |
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 I think it nice to have some convention on the ID: that way, STS can drop the things it does not understand. |
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 |
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. |
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. |
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. |
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).
The text was updated successfully, but these errors were encountered: