Maven multimodule project woes, and fixes.

[cowboysmall]

Hi,

I'm pretty new to neovim. I recently started using it with nvchad. All has been pretty smooth apart from nvim-java which I am having terrible difficulty getting to work. I have added the configuration as best as I could follow from the examples provided, but lombok is not working - for example I include a screenshot:

Any idea how I can get lombok to work with nvim-java? Or maybe it is not supported? Should I try using nvim-jdtls instead?

Thanks in advance.

[logrusx]

Looks like #399. Look at the comments where I go through the process with the reporter.

You can also see the starter-kickstart repo for relevant example.

And you can share your config to see if I can spot anything.

[cowboysmall]

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.

[logrusx]

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

[cowboysmall]

Thanks for the headsup.

So it seems there are two values documented within lsp.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.

[logrusx]

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

[logrusx]

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

[cowboysmall]

Thanks for your time and response.

Some thoughts: with respect to other editors I use such as Sublime Text, VSCode, Zed - I usually open the editor in the root directory as follows:

> cd ~/Workspace/Personal/Proj
> subl .

So I would navigate to the project root, and then open the editor in the project root (signified by the '.' representing the current directory). This will tell the editor that the project root is the PWD, and hence any language servers will operate correctly if the editor is opened at the project root.

With respect to neovim, and language servers running within it, it takes a different approach - when a file is opened, rather than starting the language server based on the PWD, it starts from the file and works it's way up looking for a root marker, and when it find one it starts the language server from that point.

This obviously breaks down in the case of a maven multimodule project. Rather than this being a maven issue I think it illustrates a shortcomming with the root markers approach. I think if neovim supported the approaches to opening files and directories similar to the other editors it would make the language server implementation so much easier to support - for example:

nvim                   # open neovim - the PWD is the user's home directory (~)
nvim ~/explicit/path   # open neovim in a specified directory - the PWD is the provided path
nvim .                 # open neovim in the current directory - the PWD is the current directory
nvim path/to/file.txt  # open file in neovim - the PWD is the either the directory from where the command is issued, 
                       # or the direcotry where the file is contained

Not only would this make the use of neovim more consistent with other editors, it would greatly simplify the support for language servers - you would no longer have to search the tree to determine the project root - it would be the PWD.

When you explicitly open a directory with neovim by either cd-ing to the directory and invoking neovim - nvim . - or by passing the path to neovim explicitly - nvim ~/Path/To/My/Project - the project root is assumed to be the PWD.

When you open a file using neovim by passing the path of the file to neovim - nvim ~/Path/To/My/File.rs - then you don't get full language server support - just maybe syntax checking.

When you open neovim without specifying either a file or a directory then either the project root is set to the user's home directory, or there is no project root set.

In my opinion the root markers approach is problematic - some projects at an early stage are not yet under revision control, and other projects - such as maven projects - contain artefacts that break the approach. It makes sense in some cases, but it breaks down in others. I think it could be used as an option to estimate a project root, but it should not be relied upon. Specifying a root directory rather than root markers would be preferable, and would make the process of starting a language server much more stable.

For my part I would love to see this feature implemented in neovim - it would be one of the last pieces in the puzzle with respect to transferring my workflow from subl, code, or zed to nvim.

I appreciate this might not be the place to discuss this - I may post something on reddit to see what others think about it. I am not sure what the neovim community is like as I am pretty new to it - hopefully they will be kind.

Thanks again for your time.

[logrusx]

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 think vim.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 the root_markers approach.

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

[logrusx]

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.

[cowboysmall]

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.

[logrusx]

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.

[cowboysmall]

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.