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:
# ~.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:
├── 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.
I've recently had cause to install
jdtlsmyself, 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 ofjdtlswhen 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 pluginsTools I'm using are creating layouts like so:
├── bin │ ├── jdtls │ └── jdtls.py └── share └── java └── jdtls ├── config_linux ├── features └── pluginsWhile 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 newdefcustomforlsp-java-server-jar-locationand check there first if non-nil.defcustomfor the path prefix of the JAR location within the install dir -- something like(defcustom lsp-java-server-jar-subpath "plugins").defcustomfor the JAR location function itself, setting the current function as the default implementation.Thanks so much for the excellent tools, y'all.