eruizc-dev / jdtls-launcher

The simplest way to install and launch JDTLS
MIT License
76 stars 6 forks source link

Using multiple runtimes without "... is not a project file.." #25

Closed lesad closed 1 year ago

lesad commented 1 year ago

Hi! The launcher works fine on projects using Java 17 but I can't get it to work with older versions. Here is my setup (fresh install):

jdtls-launcher v1.2.0
equinox-launcher 1.6.400.v20210924-0641
jdtls-core 1.25.0.202306120514
lombok custom
openjdk 17.0.7 2023-04-18
OpenJDK Runtime Environment Temurin-17.0.7+7 (build 17.0.7+7)
OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (build 17.0.7+7, mixed mode, sharing)

Neovim config:

local present, jdtls = pcall(require, "jdtls")
if not present then
    return
end

local home = os.getenv "HOME"
local java = home .. "/.sdkman/candidates/java"
local root_markers = { "gradlew", "mvnw", ".gitignore", ".git" }

jdtls.start_or_attach {
    flags = { debounce_text_changes = 80 },
    root_dir = jdtls.setup.find_root(root_markers),
    on_attach = function(client, bufnr)
    require("plugins.configs.lspconfig").on_attach(client, bufnr)
    client.server_capabilities.documentFormattingProvider = true
    client.server_capabilities.documentRangeFormattingProvider = true
  end,
    capabilities = require("plugins.configs.lspconfig").capabilities,
    cmd = { "jdtls" },
    settings = {
        java = {
            signatureHelp = { enabled = true },
            contentProvider = { preferred = "fernflower" }, -- Use fernflower to decompile library code
            -- Specify any completion options
            completion = {
                favoriteStaticMembers = {
                    "org.hamcrest.MatcherAssert.assertThat",
                    "org.hamcrest.Matchers.*",
                    "org.hamcrest.CoreMatchers.*",
                    "org.junit.jupiter.api.Assertions.*",
                    "java.util.Objects.requireNonNull",
                    "java.util.Objects.requireNonNullElse",
                    "org.mockito.Mockito.*",
                },
                filteredTypes = {
                    "com.sun.*",
                    "io.micrometer.shaded.*",
                    "java.awt.*",
                    "jdk.*",
                    "sun.*",
                },
            },
            -- Specify any options for organizing imports
            sources = {
                organizeImports = {
                    starThreshold = 9999,
                    staticStarThreshold = 9999,
                },
            },
            -- How code generation should act
            codeGeneration = {
                toString = {
                    template = "${object.className}{${member.name()}=${member.value}, ${otherMembers}}",
                },
                hashCodeEquals = { useJava7Objects = true },
                useBlocks = true,
            },
            configuration = {
                runtimes = {
                    {
                        name = "JavaSE-17",
                        path = java .. "/17.0.7-tem",
                    },
                    {
                        name = "JavaSE-11",
                        path = java .. "/11.0.19-tem",
                    },
                },
            },
        },
    },
}

LSP logs (at least those that I could fine doesn't show anything suspicious, apart from this error: [ERROR][2023-06-13 11:27:35] ...lsp/handlers.lua:535 "Jun 13, 2023, 11:27:35 AM Command _java.reloadBundles.command not supported on client" LspInfo looks OK

 Press q or <Esc> to close this window. Press <Tab> to view server doc.

 Language client log: /home/adles/.local/state/nvim/lsp.log
 Detected filetype:   java

 2 client(s) attached to this buffer: 

 Client: jdtls (id: 1, bufnr: [20])
    filetypes:       
    autostart:       false
    root directory:  /home/adles/projects/moroCV/api
    cmd:             jdtls

 Client: copilot (id: 2, bufnr: [20])
    filetypes:       
    autostart:       false
    root directory:  /home/adles/projects/moroCV/api
    cmd:             node /home/adles/.local/share/nvim/lazy/copilot.lua/copilot/index.js

 Configured servers list: eslint, lua_ls, html, cssls, jsonls, prismals, bashls, rust_analyzer, kotlin_language_server, pyright

nvim --version :

NVIM v0.9.0
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wvla -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -fno-common -Wno-unused-result -Wimplicit-fallthrough -fdiagnostics-color=always -fstack-protector-strong -DUNIT_TESTING -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/home/adles/Downloads/neovim/.deps/usr/include/luajit-2.1 -I/usr/include -I/home/adles/Downloads/neovim/.deps/usr/include -I/home/adles/Downloads/neovim/build/src/nvim/auto -I/home/adles/Downloads/neovim/build/include -I/home/adles/Downloads/neovim/build/cmake.config -I/home/adles/Downloads/neovim/src -I/usr/include -I/home/adles/Downloads/neovim/.deps/usr/include -I/home/adles/Downloads/neovim/.deps/usr/include -I/home/adles/Downloads/neovim/.deps/usr/include -I/home/adles/Downloads/neovim/.deps/usr/include -I/home/adles/Downloads/neovim/.deps/usr/include -I/home/adles/Downloads/neovim/.deps/usr/include

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Run :checkhealth for more info
eruizc-dev commented 1 year ago

Hey! I personally use both java11 and java17 too and the only difference that I see is that your paths don't have a slash (/) at the end of them.

Try replacing path = java .. "/11.0.19-tem" with path = java .. "/11.0.19-tem/" and see if it works, I'll also link you my config for reference (bare in mind that vim.fn.glob will expand to a list if it finds multiple results so it will not work if you have more than 1 java 17 installed)

      configuration = {
        -- Name is NOT arbitrary: must match one of the elements from `enum ExecutionEnvironment` in the link below
        -- https://github.com/eclipse/eclipse.jdt.ls/wiki/Running-the-JAVA-LS-server-from-the-command-line#initialize-request
        runtimes = {
          { name = "JavaSE-11", path = vim.fn.glob("$SDKMAN_DIR/candidates/java/11.*/") },
          { name = "JavaSE-17", path = vim.fn.glob("$SDKMAN_DIR/candidates/java/17.*/") },
        }
      }

https://github.com/eruizc-dev/eruizc-dev/blob/master/dotfiles/xdg_config_home/nvim/ftplugin/java.lua#L31-L32

lesad commented 1 year ago

Sorry for such a delay, I have been trying to get some insights on the problem. The first thing I've tried is to use the manual approach (without your launcher). This worked as expected, the project got recognized and I've got the right suggestions.

Then I wanted to make sure that it's not project related. I have created two fresh project using Spring Initializr, one using Java 17 and the other using Java 11. This also worked as expected, either with or without the launcher.

I have also noticed some file being created on first launch with LSP (.classpath, .project, .settings) that were not present before. They did not, however, get created in the project in question. And I still got the warning.

Might I ask, how is the workspace folder for multiple different projects handled? I can't see the script making this distinction.

eruizc-dev commented 1 year ago

To be honest I'm confused, there's no special handling for any of this thing really. The only problem I can think of is that this script uses the default java version which has to be 17 for jdtls to work.

https://github.com/eruizc-dev/jdtls-launcher/blob/master/jdtls-launcher.sh#L215-L227

Can you create a repo in which jdtls-launcher fails to start so I can clone and replicate your issue?

lesad commented 1 year ago

I can't seem to replicate the issue. It seems to be project-specific but I can't share as it is private to the company I work for. I'll try to pick out the problematic part and close the issue in the meantime..