Support of several maven projects in the single workspace

[PavelSosin]

SAP WebIDE supports workspaces with several maven projects. It causes the situation when initialize is sent for every open project in the workspace to trigger maven build and indexing. Although it doesn't cause any reported error, almost all LSP functions work only for the 1st opened project. Is it limitation caused by LSP implementation or by JDT? In the eclipse IDE environment JDT successfuly serves such configuration.

[fbricon]

jdt.ls expects https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#initialize to be called once with a root uri, from which the projects are discovered

At the moment though, we're not discovering new projects after that initial initialization call, see #144.

Can you give us more details about your initialization process? How are your projects organized?

[amiramw]

The setting is one workspace that contains several projects. Each project is an independent reactor. Currently LSP should be restarted whenever wanting to get language services for another project in the workspace. It is similar to the way eclipse workspace can contain several independent java projects for which language services are available.

[fbricon]

Ok so this one is tricky. vscode is introducing the concept of multiple root workspaces so we'll have to figure out how to cope with that in jdt.ls.

One basic solution could be to run an instance of jdt.ls per root folder, but you couldn't have workspace resolution between modules of different reactors in the same workspace.

Alternatively, running a single jdt.ls instance for multiple root folders would save on used resources and provide global workspace resolution but that could also be seen as reactors leaking modules to one another. Still, that's the way Eclipse works so it's probably ok.

@aeschli any advice?

[aeschli]

It would be great if we can support multiple root folders by looking for projects in all of them. If I understand the current code correctly, the Maven import already scans the folder hierarchy and imports any folder with a pom file. So it should just be an extension to the scanning code. There's still more work to do of course to support multi roots, but running a single LS would be most efficient.

[amiramw]

Do you have any idea how other implementations of the LSP (for other languages) treat several projects in a workspace?

[gorkem]

We probably should have one language server per workspace. I presume the reason for collecting multiple root folders to a workspace is that they are somewhat related and a language server should follow suit. I think we need extensions to LSP to properly support this. Filed https://github.com/Microsoft/language-server-protocol/issues/281 to follow up.

[aeschli]

IMO we should try to avoid multiple servers for the following reasons:

• performance, double the memory footprint
• maintainability: Eclipse workspaces means multiple, likely overlapping progress reports, multiple error log files...
• unhappy user experience towards symbols in shared libraries such as the JRE:
  • duplicated entries in workspace symbols
  • reference/implementers code lens on these elements will be limited to an Eclipse workspace

I don't see any real issues with sharing the same Eclipse workspace for all root folders. Some challenges:

• Need to pay extra attention to project names as they can need to be unique in a workspace. I'd suggest qualify them with the root name. Project names can show up error messages and, I guess, are used by the maven classpath container.
• In VSCode, currently, switching from simple folder to multiple folders will result in a new storage area location and therefore a new Eclipse workspace that will be initialized. I'll check what we can do in VSCode to avoid that.

[aeschli]

@amiramw We try to encourage all language server try to add support so that multiple roots can be supported by the same server. For most languages that works well. The only language I'm aware right now which conclused they need a server per folder approach is C++.

[PavelSosin]

Personally, I would prefer that "initialize" will refer Workspace root and project type specific functions like build and Symbol table initial building will be triggered by "didOpen" of project meta files like pom.xml, package.json, etc. IDE has to inform LSP Server that certain project came to scope via didOpen of project meta file - it handles workspace anyway and knows what is the "project" at all. From other hand LSP server implementations knows better what to do in the case of new project is created or existing project meta is updated.

[PavelSosin]

Sorry, closed by mistake

[gorkem]

Now that we have multi-root workspaces fully supported is there anything else left here to do ? @fbricon

[ghost]

@gorkem how it works? run in the root directory?

[tsmaeder]

@fbricon @gorkem I still don't think multi-root support completely covers the case of new projects. They could also be created as a subfolder of a preexisting project (for maven, for example). Methinks the only way to really solve this is to react to the creation of relavant files (pom.xml, etc.)