Multimodule Maven project

[mnd999]

When working on a large multimodule maven project, nvim-metals seems to put the .metals and .bloop folders in the root of the module containing the file being edited, instead of at the root of the project as CoC used to do. Is this expected? It seems to quickly result in a lot of these folders building up around the project, so I suspect I am doing something wrong.

[ckipp01]

Hey @mnd999, good question. The root detection of both coc-metals and nvim-metals works slightly different. When using nvim-metals it will traverse down the file structure until it reaches a build file. Once it does, it will also look to see if there is another in the parent directory to account for workspaces that have layered build files like some multi-module projects do. What does the file structure look like in your project and where are your pom files? Are they separated by more than a single level?

[mnd999]

I'm on the neo4j repository (https://github.com/neo4j/neo4j) and I attempt to edit one of the tests e.g. nvim community/community-it/cypher-it/src/test/scala/org/neo4j/cypher/CommunityUserAdministrationCommandAcceptanceTest.scala.
I see the community/community-it/.metals/ folder get created when I would expect it to be in the current directory. I see .pom files at each level:

markslaptop% ls pom.xml
pom.xml
markslaptop% ls community/pom.xml
community/pom.xml
markslaptop% ls community/community-it/pom.xml
community/community-it/pom.xml
markslaptop% ls community/community-it/cypher-it/pom.xml
community/community-it/cypher-it/pom.xml

Interestingly, it's getting created one level up from the test, but not at the top level or the test level. It also fails because metals is using it's own maven version and that is too old, but that is another issue.

[ckipp01]

Alright so I just took a look at neo4j, this behavior actually make sense, and matches what I mentioned above. The logic in nvim-metals is to go two layers deep. You can see this in

nvim-metals/lua/metals/rootdir.lua

Lines 14 to 40 in 58ecfb6

	--- NOTE: This only searches 2 levels deep to find nested build files.
	--- Given a situation like the below one where you have a root build.sbt
	--- and one in your module a, you want to ensure the root is correctly set as
	--- the root one, not the a one. This checks the parent dir to ensure this.
	--- build.sbt <-- this is the root
	--- a/
	--- - build.sbt <- this is not
	--- - src/main/scala/Main.scala
	local find_root_dir = function(patterns, startpath)
	local path = Path:new(startpath)
	-- TODO if we don't find it do we really want to search / probably not... add a check for this
	for _, parent in ipairs(path:parents()) do
	local pattern = has_pattern(patterns, parent)
	if pattern then
	local grandparent = Path:new(parent):parent()
	-- If the pattern is found, we don't check for all patterns anymore,
	-- instead only the one that was found. This will ensure that we don't
	-- find a buid.sc is src/build.sc and also a .git in ./ causing it to
	-- default to that instead of src for the root.
	if has_pattern({ pattern }, grandparent) then
	return grandparent.filename
	else
	return parent
	end
	end
	end
	end

So it finds the first pom.xml in community/community-it/cypher-it/pom.xml and then the second inside of community/community-it/pom.xml and then goes no further, and marks that as root. In more simple builds, and in most sbt projects (which most users use), this is no issue, and works like 95% of the time. However you're not the first one to hit on this, in reality, you're the 3rd one to create an issue/question about it, so I think it's time to change this logic.

I see two different ways forward.

1. We traverse down until we don't find anymore build files. So in this example the room pom.xml would be found and then the parent directory wouldn't have one, so then the root would be correctly marked. The only danger of this is that technically we'd be looking at the parent of the actual workspace at times, and I really want to avoid ever going too deep and marking something not even in your workspace as the root. Will this ever happen? No idea, but who knows.
2. Secondly, and someone else suggested this would be to add in a custom depth setting. Right now it searched for 2, but a user could pass in 4 for this situation, and then it would continue to look for pom.xml files 4 layers deep. This could also work, but would require the user to see how deep they are nested and mark it.

I'm not 100% sure which option would be best so I might think on this a bit. I'll create an issue out of this conversation. In the meantime, something you could do is override the find_root_dir with your own function that finds the root or just sets it like this:

metals_config.find_root_dir = my_find_root_dir

Then my_find_root_dir is just a function that takes in patterns and a startpath. For example others have done this using an env var.

Let me know if you have any questions on this for now as a workaround, and I'll hopefully get a proper fix for this soon.