You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've recently had cause to install jdtls myself, rather than using lsp-mode's auto-install faculty. Unfortunately, this can get a little messy. The issue at hand is the function lsp-java--locate-server-jar, and the directory layout of jdtls when it's installed by alternative tools. Specifically, lsp-mode's installation creates a structure like this:
├── bin
│ ├── jdtls
│ └── jdtls.py
└── share
└── java
└── jdtls
├── config_linux
├── features
└── plugins
While this installation is valid, it breaks JAR detection, so LSP won't start -- even though it can find the "server command".
I can see a couple very reasonable solutions here, and I'm happy to implement whichever solution y'all prefer.
Right now, jar location searches in lsp-java-server-install-dir; we could add a new defcustom for lsp-java-server-jar-location and check there first if non-nil.
We could add a new defcustom for the path prefix of the JAR location within the install dir -- something like (defcustom lsp-java-server-jar-subpath "plugins").
We could make a new defcustom for the JAR location function itself, setting the current function as the default implementation.
Thanks so much for the excellent tools, y'all.
The text was updated successfully, but these errors were encountered:
I recently ran into this, it happens for instance when installing via nix (by the structure listed, I'm guessing that's your use-case too?), a temporary workaround I found is to add :around advice to lsp-java--locate-server-jar, with a simple function such as:
(defunjava-server-subdir-for-jar (orig&restargs)
"Add nix subdir to `lsp-java-server-install-dir' so that the lsp testsucceeds."
(let ((lsp-java-server-install-dir
(expand-file-name"./share/java/jdtls/" lsp-java-server-install-dir)))
(apply orig args)))
(advice-add'lsp-java--locate-server-jar:around#'java-server-subdir-for-jar)
Additionally, when talking about a more permanent solution, I see a different (maybe complementary) possibility to add to the list. Currently, there is lsp-java-jdt-ls-prefer-native-command to choose between using the jar invocation or the executable invocation; if that is t, it should probably not check for the presence of the jar at all. Adding a separate variable for the jar is still a good idea though.
I've recently had cause to install
jdtls
myself, rather than usinglsp-mode
's auto-install faculty. Unfortunately, this can get a little messy. The issue at hand is the functionlsp-java--locate-server-jar
, and the directory layout ofjdtls
when it's installed by alternative tools. Specifically,lsp-mode
's installation creates a structure like this:# ~.emacs.d/.cache/lsp/eclipse.jdt.ls/ drwxr-xr-x@ - rdonaldson 19 Sep 16:03 bin drwxr-xr-x@ - rdonaldson 19 Sep 16:03 boot-server drwxr-xr-x@ - rdonaldson 19 Sep 16:03 bundles drwxr-xr-x@ - rdonaldson 19 Sep 16:15 config_linux drwxr-xr-x@ - rdonaldson 19 Sep 16:03 config_mac drwxr-xr-x@ - rdonaldson 19 Sep 16:03 config_ss_linux drwxr-xr-x@ - rdonaldson 19 Sep 16:03 config_ss_mac drwxr-xr-x@ - rdonaldson 19 Sep 16:03 config_ss_win drwxr-xr-x@ - rdonaldson 19 Sep 16:03 config_win drwxr-xr-x@ - rdonaldson 19 Sep 16:03 features drwxr-xr-x@ - rdonaldson 19 Sep 16:03 java-decompiler drwxr-xr-x@ - rdonaldson 19 Sep 16:03 java-test drwxr-xr-x@ - rdonaldson 19 Sep 16:03 plugins
Tools I'm using are creating layouts like so:
While this installation is valid, it breaks JAR detection, so LSP won't start -- even though it can find the "server command".
I can see a couple very reasonable solutions here, and I'm happy to implement whichever solution y'all prefer.
lsp-java-server-install-dir
; we could add a newdefcustom
forlsp-java-server-jar-location
and check there first if non-nil.defcustom
for the path prefix of the JAR location within the install dir -- something like(defcustom lsp-java-server-jar-subpath "plugins")
.defcustom
for the JAR location function itself, setting the current function as the default implementation.Thanks so much for the excellent tools, y'all.
The text was updated successfully, but these errors were encountered: