Not possible to configure projects sources for LS launched on standalone machine

[gazarenkov]

LS always expects source code on the same path as it configured for "ws-agent" machine (machine where Project API located).
Inability to configure this path limit using it on in case when LS launched in standalone machine (a k a sidecar) especially for the cases when there are no permissions to use the same dir or LS image is provided by third party.

[tsmaeder]

I'm not really sure what you're trying to achieve here: should a URI like file:///projects/project1/pom.xml be mapped to something like file:///groupdir/mylocation/project1/pom.xml in all requests to the language server?

[tsmaeder]

If there is no urgent requirement behind this change, I would ask that we postpone it until we have switched to jdt.ls

[gorkem]

I thought we did not have plans to introduce side-cars to Che 6 line?

[gazarenkov]

@gorkem we've supported it for a quite long time (6+ months I guess), I'd like it to work independently on permission in particular container configuration, stuck up with this bug.

@tsmaeder yes, it's quite critical bug, let's not block it "by default". thanks

[tsmaeder]

@gazarenkov could you share some more details on which language server you're trying to enable? Maybe there is an alternative way to work around the problem.

[gazarenkov]

@tsmaeder sure, I am working with Type Script language server (dogfooding Che for client side code) as a standalone docker container and have no ability to have the same projects folder mount path for it and ws-agent.

[tsmaeder]

@gazarenkov I still don't see why we can't point the typescript language server at /projects and mount that directory in the image. They need to be the same files anyway, because ws-agent is changing those files on disk.

[gazarenkov]

@tsmaeder thanks for being reactive :)

In my case I can not physically, indeed, since I use local machine and source code is not on the root directory level (apparently coding under root user is not the choice).

But even if not taking it into account, we already have ability to mount projects to any directory, it is documented feature and it is expected that any application using source code have to respect this.
That's actually why it is qualified as bug.
HTH

[tsmaeder]

@gazarenkov mounting the projects is fine, but it has to be in the same directory on both machines. I have objections against this PR for two reasons:

1. Let's at least postpone it until jdt.ls is merged. If you want to speed that process up, let's work on stuff like Consistent Lifecycle Events for Projects #9924
2. This will break any Theia language server plugin that extends the protocol or uses custom commands. One of the benefits of moving to theia was that we can stop mangling the workspace paths and jdt uri's.

[gazarenkov]

@tsmaeder
I believe hardcoding "/projects" folder is not a way to go, we started with it for simplicity and then made it configurable a long time ago. As I explained previously, LSP seems the only place not respecting this, so it is a bug which has to be fixed.
As stated, this is optional setting, default is exactly as you expected so it is safe fix.
Now, I understand your worries about big feature branch merging (it is not a unique situation) so you can rely on any help if something with it goes wrong.
Please unblock the PR (it is much better than it will do someone else), thanks.

[dkuleshov]

Seems like after jdt.ls branch is merged there are some inconsistencies in related pull request, I see some changes to text document service and language server configuration, probably in some other places too. So we will first need to resolve conflicts, revise the pull request and adapt the solution to newly introduced changes.