Skip to content
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

Feature Request/Proposal: Customize jdtls Jar Location #487

Open
rectangular-zone opened this issue Sep 20, 2024 · 1 comment
Open

Feature Request/Proposal: Customize jdtls Jar Location #487

rectangular-zone opened this issue Sep 20, 2024 · 1 comment

Comments

@rectangular-zone
Copy link

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.

  1. 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.
  2. 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").
  3. 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.

@LuigiPiucco
Copy link

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:

(defun java-server-subdir-for-jar (orig &rest args)
      "Add nix subdir to `lsp-java-server-install-dir' so that the lsp test
succeeds."
      (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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants