I have only ever been running nvim from the project root - i.e. the parent project directory - in general I would never open a child module of a multimodule project in isolation of it's parent and siblings.

I assume that nvim-java interracts with jdtls, and provides it with the project root directory using the root_markers - I think the way it finds and determines the project root directory is flawed - proof of which is that my achange above resolved the issue.

I don't think it relates to jdtls itself because I am using jdtls in sublime text (LSP-jdtls) and this is not, and never has been, an issue.

If you clone the repo, have in mind there's another - nvim-java-core, where the LSP stuff happens.

Thanks for the headsup.

So it seems there are two values documented withinlsp.lua (within the core neovim project) that relate to the root directory of a project:

@field root_dir? string|fun(bufnr: integer, on_dir:fun(root_dir?:string))@field root_markers? (string|string[])[]

root_markers is used to figure out the root of the project, and root_dir is the explicit root of the project. If root_dir is provided, the root_markers is ignored.

root_dir can be either a string or a function - a function would be useful because the evaluation of where the root directory is could be deferred till after the lsp client has been created.

I tried adding root_dir to the java setup config - instead of configuring root_markers - but it didn't seem to work.

If you assume that the directory neovim is opened from is the project root then finding the project root should be trivial by passing neovim's PWD to the language server using the root_dir property.

Maybe integration with project.nvim or similar could be beneficial.

You've raised an interesting topic thank you! I almost certainly will join the effort when I get back home.

project.nvim looks interesting - I will look into it. Before I try your change, I have a few questions:

* project.nvim seems to determine the project root in a similar fashion to the existing `root_markers` approach - is there a benefit to using project.nvim rather than just changing the default nvim-java root markers to be the same as the project.nvim patterns (used in it's own detection method)?

Project.nvim allows for switching projects on the fly. Although I don't think nvim-java supports changing the project on the fly. At least not jdtls-wise. Which might be implemented as well. I can look in that direction too.

It also maintains a list of recently opened projects.

I've been using project.nvim since I started using Neovim and it does some stuff silently under the hood but I don't remember anymore what it was, because it requires nothing from your side.

Here's an extension for fzf-lua:https://github.com/jakobwesthoff/project-fzf.nvim/

* instead of using project.nvim what about using one of the functions provided by nvim itself such as `vim.loop.cwd()` or `vim.fn.getcwd()` to determine the root - if necessary the root determined from the function calls can be checked against the root markers, and if it does not contain any of the root markers then the original approach of searching the tree continues.

No idea but I thinkvim.fn.getcwd() is the fallback in the current code. You could very well just make it the first choice.

* as an even simpler fix, what about changing the default neovim-java root markers from what they are to the same as project.nvim patterns? In other words, the project root is the directory that contains .git files, or .hg files, etc. and if a user doesn't agree they can override the `root_markers` with something specific to their needs.

As I said it does a bit more and not all projects contain .git.

I'm not sure if I understand how the lsp detection method works, but I think the pattern detection method would seem to be the same as theroot_markers approach.

I'm not sure either, but if it's true lsp detection, then jdtls must be perfectly capable doing that for itself.

I'm actually using this fork:https://github.com/ansidev/project.nvim. Its commit log contains something about workspace_folders which I don't understand.

Project.nvim allows for switching projects on the fly...

I will definitely have to look into this. If I understand correctly, it allows you to change from project to project - selected from a list of previously opened projects maintained by the plugin. If that is the case, then I assume the language server will have to be re-created when the project is (re) opened and killed when the project is closed or changed?

And thanks for the links - I am quite new to nvim so any recommendations are appreciated greatly.

No idea but I think vim.fn.getcwd() is the fallback in the current code. You could very well just make it the first choice.

That might be the way to go. Definitely worth checking out.

As I said it does a bit more and not all projects contain .git.

I said the same earlier in this discussion.

I still think the best approach is to determine the project root based upon the directory that nvim is opened in - which should be returned by the two functions I referenced above. This makes the most sense IMHO - and is consitent with all other editors I use (such as subl, zed, code, etc.) - but that's perhaps a different discussion.

Project.nvim allows for switching projects on the fly...

I will definitely have to look into this. If I understand correctly, it allows you to change from project to project - selected from a list of previously opened projects maintained by the plugin. If that is the case, then I assume the language server will have to be re-created when the project is (re) opened and killed when the project is closed or changed?

Same thoughts on my side.

And thanks for the links - I am quite new to nvim so any recommendations are appreciated greatly.

I too. Only e few months.

I still think the best approach is to determine the project root based upon the directory that nvim is opened in - which should be returned by the two functions I referenced above. This makes the most sense IMHO - and is consitent with all other editors I use (such as subl, zed, code, etc.) - but that's perhaps a different discussion.

I think the same way.

I was just considering what other editors I've used do.

1. Eclipse - you don't start eclipse in a particular directory, but you chose a workspace which contains projects.
2. Idea - the same.
3. NetBeans - the same.

I haven't used other Java IDE's. The common denominator of all of the above is they are graphic stand-alone applications which set everything for themselves and the difference with Neovim is you use it in the terminal where some things are already set for the editor.

But it also depends on patterns of usage.

I also use IntelliJ - I've been using it since the early 2000s (yes, I am that old) - never cared much for either eclipse or netbeans. Most of my commercial work has been using Java - definitely not my favourite language, but that is the nature of the market where I am from.

With the exception of IntelliJ I am not a fan of IDEs - I find them way too heavyweight and slow - which is why I gravitate towards lighter editors that I can configure with whatever I want or need to help with my editing.

Consioder checking out Sublime Text, Zed, and Visual Studio Code. I am a big fan of Sublime Text, and amd rapidly warming to Zed. VSCode is pretty good too, but a little heavyweight.

As opposed to IDEs, these editors behave quite similarly - there is no need to create a workspace or project - all you need to do is open the editor in the root directory of the project and you are good to go - see the attached screenshot for an example of Sublime Text where I opened subl in the root of a project I recently started working on:

I would love if this kind of behaviour would be possible in neovim - opening neovim in the root directory of a project and getting all of the goodness for free.

I think neovim is very close to a first class editor - on a par with Sublime Text or Zed - that lives in a terminal. Most of the tools I use are terminal based / TUIs so if I could use neovim instead of subl or zed I would be very happy.