williamboman / nvim-lsp-installer

Further development has moved to https://github.com/williamboman/mason.nvim!
https://github.com/williamboman/mason.nvim
Apache License 2.0
2k stars 123 forks source link

jdtls: use root_dir for -data parameter (instead of cwd) #501

Closed TheBlob42 closed 2 years ago

TheBlob42 commented 2 years ago

Problem description

In the init.lua file for the jdtls server the workspace folder is created by default using a "base workspace path" plus the last part of the current cwd (see here). I am wondering why we don't use the also available root_dir of the current Java project which is given to the function (see here) instead? This way we would get the actual project name instead of the last part of the cwd.

I am usually starting Neovim in my home directory and then do all navigation inside of it. Therefore my cwd is always /home/user/. As a consequence whenever I open a Java project the corresponding workspace folder points to the same folder: /home/user/workspace/user even when I have multiple Java projects open. This obviously causes problems like for example that my project dependencies can not be found etc.

I have build a "hack" in my config to change the cmd from nvim-lsp-installer to better point to an individual workspace folder per project (using the root_dir), but I though maybe this should be changed within the plugin. But maybe this was done on purpose and there are use cases in which my approach would cause other problems :thinking:

Neovim version (>= 0.6)

NVIM v0.6.1 Build type: RelWithDebInfo LuaJIT 2.1.0-beta3

Operating system/version

Linux DTC69Y2 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I've recently downloaded the latest plugin version of both nvim-lsp-installer and nvim-lspconfig

Affected language servers

jdtls

Steps to reproduce

  1. start Neovim using the minimal config: nvim -u ~/Downloads/minimal_debug_init.lua
  2. install jdtls using: LspInstall jdtls
  3. open a Java file within a Java project e.g. :e <path-to-file>/MainClass.java
  4. check the -data directory
    • use :LspInfo
    • check cmd and there the -data path

Actual behavior

-data argument is /home/<user>/workspace/<user>

Expected behavior

-data argument should be /home/<user>/workspace/<project-name>

LspInfo

Language client log: /home/user/.cache/nvim/lsp.log
 Detected filetype:   java

 1 client(s) attached to this buffer: 

 Client: jdtls (id: 1, pid: 33257, bufnr: [1])
    filetypes:       java
    autostart:       true
    root directory:  /home/user/git/mappy-v2-gui
    cmd:             java -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.eclipse.jdt.ls.core.product -Dlog.protocol=true -Dlog.level=ALL -Xms1g -Xmx2G -javaagent:/home/user/.local/share/nvim/lsp_servers/jdtls/lombok.jar --add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED -jar /home/user/.local/share/nvim/lsp_servers/jdtls/plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar -configuration /home/user/.local/share/nvim/lsp_servers/jdtls/config_linux -data /home/user/workspace/user

 Configured servers list: jdtls

Healthcheck

nvim-lsp-installer: require("nvim-lsp-installer.health").check()
========================================================================
## nvim-lsp-installer report
  - OK: neovim version >= 0.6.0
  - WARNING: **Ruby**: not available
  - WARNING: **RubyGem**: not available
  - WARNING: **julia**: not available
  - OK: **tar**: `tar (GNU tar) 1.30`
  - OK: **gzip**: `gzip 1.10`
  - OK: **wget**: `GNU Wget 1.20.3 built on linux-gnu.`
  - OK: **python3**: `Python 3.8.10`
  - OK: **Go**: `go version go1.17.3 linux/amd64`
  - OK: **sh**: `Ok`
  - OK: **bash**: `GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)`
  - OK: **PHP**: `PHP 7.4.3 (cli) (built: Nov 25 2021 23:16:22) ( NTS )`
  - OK: **node**: `v14.17.6`
  - OK: **curl**: `curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3`
  - OK: **java**: `Ok`
  - OK: **Composer**: `Composer 1.10.1 2020-03-13 20:34:27`
  - OK: **javac**: `javac 17.0.1`
  - OK: **npm**: `7.24.1`
  - OK: **pip3**: `pip 21.3.1 from /home/user/.local/lib/python3.8/site-packages/pip (python 3.8)`

Screenshots or recordings

No response

williamboman commented 2 years ago

Hello! Ah I see. I've pushed a little something to jdtls-workspace-dir (#504), does it work as you'd expect?

TheBlob42 commented 2 years ago

Thank you for the fast response. I tested it with the minimal_debug config and that works fine now :+1:

For my personal config I use nvim-jdtls and therefore puzzle the server config together myself before handing it to the plugin. In there I use jdtls_server:get_default_options().cmd to use the jdtls installed by your plugin. Unfortunately for me the "default cmd" still points to the cwd, so that the problem persists. I realize that I have not add this information in the issue description (but at least it is fixed for the "default case" now)

Do you have any idea if this case could also be solved? Otherwise I need to stick with my hack.

TheBlob42 commented 2 years ago

Nevermind I figured out an easy solution (shortened to just present the basics):

local root_dir = require('jdtls.setup').find_root({ 'gradlew', '.git', 'pom.xml', 'mvnw' })
local config = { ... }
local server_available, jdtls = require('nvim-lsp-installer.servers').get_server('jdtls')

-- this will fill in the correct 'cmd' to use
jdtls:get_default_options().on_new_config(config, root_dir)

require('jdtls').start_or_attach(config)

So your change is indeed solving this as well :slightly_smiling_face:
(since the on_new_configfunction did not accept the workspace_path parameter before)

williamboman commented 2 years ago

Ah, cool! A bit hacky but if it works it works :D. Feel free to add your solution to the Wiki!