JDT_LS_PATH env var to reference local JDT-LS build #3152
Conversation
|
Nice. I'll give it a try. So basically this is a way for developers who may want to test in VS Code (or verify they aren't breaking VS Code) but they don't want to set NodeJS/NPM and perform that aspect of the build. This solution allows them to hijack an existing vsix, and just swap out JDT-LS. Definitely a "user at your own risk" but it would reduce the barrier to entry for some. |
mickaelistria
force-pushed
the
JDT_LS_PATH
branch
from
65072cb to
a9cf48f
Compare
There was a problem hiding this comment.
Works well for me! Some good news. Everything I said about needing to clean up the configuration being stored in the globalStorage/ folder doesn't apply. We create the location in resolveConfiguration(context, configDir) but your code will never take that path, so we can leave the contents completely untouched and the user can go back to their normal setup when they remove the JDT_LS_PATH environment variable!
CONTRIBUTING.md
Outdated
| - Clear the workspace state: `$ rm -r /home/userId/.config/Code/User/workspaceStorage/0123456789abcdef01234567890abcdef/redhat.java/jdt_ws` | ||
| - Start VSCode with the `JDT_LS_PATH` environment variable set to the local copy of JDT-LS you want to try: `$ JDT_LS_PATH=/home/userId/git/eclipse.jdt.ls/org.eclipse.jdt.ls.product/target/products/languageServer.product/linux/gtk/x86_64 code` | ||
|
|
||
| Most other options such as `DEBUG_VSCODE_JAVA` are still usable with this approach.4 |
There was a problem hiding this comment.
'4' is just a typo here and can be removed I think.
mickaelistria
force-pushed
the
JDT_LS_PATH
branch
from
a9cf48f to
dd59f0e
Compare
|
@rgrunber all suggestions should have been addressed now. |
No description provided.