Conversation
|
Tried this, looks really awesome. Great work. One minor polish could be to change the label of the quick fixes to be a little more precise and self-explaining. For example instead of:
We call it:
In case a web config already exists, it should instead be something like:
And similarly for properties, so that users know more precisely what will happen when they execute the quick fix... 😀 |
a11ff60 to
03dd474
Compare
|
I've corrected the labels. Should be done from my perspective. Still rewrite recipe for the quickfix for this one. |
|
I tried the latest changes from the branch and the quick fixes for the web config beans are somehow broken. Invoking them throws this on the language server side: |
|
Hmm... that is interesting indeed... the tests pass and I specifically put in integration test to go cover the FixDescritpor -> recipe execution bit (so recipe deserialization). I'll investigate... but sad that the test didn't catch this despite all of my efforts |
Signed-off-by: BoykoAlex <alex.boyko@broadcom.com>
Signed-off-by: BoykoAlex <alex.boyko@broadcom.com>
ab81692 to
11cff66
Compare
|
@martinlippert The inconsistency between test harness and live LS process is from different
More replacement for |
Signed-off-by: BoykoAlex <alex.boyko@broadcom.com>
|
Great findings, glad you found the root cause of this! |
|
Testing the latest version here. If I have a properties file called |
|
There is also the question of whether we want the property quick fix variant working even if there is no properties file at all, similar to there is no web config class, so that the quick fix would create an |
|
I also see issues with deleting or creating files not causing the overall validation to be re-run to update the quick fixes accordingly, but I would track and tackle that in a separate issue once we have this one in. I can then look into the polish for when validations are re-triggered later. |
Fixes #1659