Multi-root Che Theia Workspaces

[azatsarynnyy]

Is your enhancement related to a problem? Please describe.

A lot of VS Code extensions require multi-root layout to work properly.
To set up a multi-root Che Theia Workspace, one needs to do several repetitive steps on each start of Che Workspace.

Describe the solution you'd like

Che Theia should automatically switch the layout of the users' projects to a multi-root Che Theia Workspace.

Since not all of VS Code extensions are supporting multi-root mode yet,
Che Theia should provide a command to quickly switch between multi/single root modes.

Switching to a multi-root mode should happen as earlier as possible, e.g.:
1/ clone the projects
2/ convert each project to a Workspace root
3/ LS initialization, import Commands as Tasks, etc.

As multi-root mode affects several areas (LS, Tasks, etc.),
it's not expected to get a completely working solution as a result of this issue.
It may be PoC of the described idea, at least. Then, we'll see if some areas require more adaptation.

Additional context

https://code.visualstudio.com/docs/editor/multi-root-workspaces

Sub-tasks

• Change config storage paths from /home/theia/home/theia to the corresponding paths Change config storage paths from /home/theia/home/theia to the corresponding paths #18548

[sunix]

@azatsarynnyy isn't it a duplicate of #15347?

[azatsarynnyy]

@azatsarynnyy isn't it a duplicate of #15347?

it isn't, as #15347 is about persisting in devfile, and this one is about automatic switch the layout

[sunix]

ok I have just referenced this one as the second item of #15529

[tsmaeder]

Some stuff will be broken if we move to multi-root: #17191

[tsmaeder]

There is also already an open PR from @JPinkney introducing workspace-root per project here: eclipse-che/che-theia#408

[azatsarynnyy]

Thanks, Thomas! We'll take a look at it as well.

[azatsarynnyy]

I've renamed the issue to "Multi-root Che Theia Workspaces , by default"
in order to reflect our plan to make a multi-root mode optional at the first iteration.
Once we decide it's stable enough, we will enable it by default for all workspaces.

[RomanNikitenko]

There are couple questions about preferences for the multi-root mode, so I would like to discuss the topic here.

It's expected for theia that some preferences are stored in the workspaceFolder/.theia/settings.json.
So setting preference to ${CHE_PROJECTS_ROOT}/.theia/settings.json for master branch works well because ${CHE_PROJECTS_ROOT} is a workspace folder by default.

For a multi-root workspace it's expected that preferences are stored in workspace config file, like che.theia-workspace.
So, for the case like this the preference is stored to workspace config file /projects/che.theia-workspace and it is available under the Workspace scope of settings, please see eclipse-che/che-theia#778 (comment)

For the case, like this one a multi-root workspace knows nothing about the preference, as ${CHE_PROJECTS_ROOT} is NOT a workspace folder, so the preference is ignored.

I could provided some logic for the multi-root mode and export preferences from ${CHE_PROJECTS_ROOT}/.theia/settings.json to /projects/che.theia-workspace, but for me it makes sense only if it's expected that a user wants to turn on and turn off the multi-root mode for the same workspace.
For this case we have to handle both exports:

• ${CHE_PROJECTS_ROOT}/.theia/settings.json ===> /projects/che.theia-workspace
• /projects/che.theia-workspace ===> ${CHE_PROJECTS_ROOT}/.theia/settings.json

Also we should think about conflicts or just overwrite preferences at switching the multi-root mode - if preferences are not equal.

Note: As I mentioned above - I don't see any problems and we don't need provide any logic to export preferences for the case like this - it's handled automatically for both modes: multi-root is ON and OFF.

To be honest I'm not sure that it's usual use case for che and expected behavior - if a user creates Go or Java maven multi-root workspace - does the user want to turn off the multi-root mode after a workspace creation?
But sure we can handle such case if it's required. Maybe I missed other use cases related to ${CHE_PROJECTS_ROOT}/.theia/settings.json ===> /projects/che.theia-workspace

@benoitf @azatsarynnyy @ericwill @tsmaeder
please share your opinion
Thanks in advance!

[tsmaeder]

tl:dr:

1. There will be only multi-root workspaces in the future. Don't worry about migration
2. Preference values should be merged the same way as tasks
3. We need to implement the proper workaround I sketched in Allow to define VS Code extensions preferences in Che plugin registry #17975 (comment)

A couple of high-level thoughts here:

First off: I don't think "single-root" mode should exist after a period of transition: they will all be multi-root workspaces, even if they only contain a single project. From a UI point of view, it should not make a difference to the user. Therefore, we should not concern ourselves with single-root when we think about long-term solutions. If we want to prevent losing user settings in existing workspaces, we should write some one-time migration code and keep it separate from the mainline code. But IMO, I don't think we should bother. "Single" vs. "multi-root" is a technical distinction of no value the the Che user.

Second: merging the preference values will have the exact same problems we have with che-command and tasks: it will be impossible to tell how to merge conflicts automatically: whatever we do, the merge policy should be the same as with other artifacts we propagate from the devfile to Theia.

Third: the issue @sunix brings up is because of our workaround for not getting a fix for #17975. Our team cannot properly fix that issue because we do not own the meta.yml format. Even though some might not like the terminology, I consider our current workaround a hack, because the mechanism for translating meta.yaml info into Theia settings should be in a single location, not recreated in each plugin meta.yml. Solving the problem in individual sidecar entrypoints creates unnecessary and implicit coupling in our code and leads to breakage (as we're seeing now) when we make changes.

[azatsarynnyy]

Thanks Roman for raising your concerns.

It's expected for theia that some preferences are stored in the workspaceFolder/.theia/settings.json.
So setting preference to ${CHE_PROJECTS_ROOT}/.theia/settings.json for master branch works well because ${CHE_PROJECTS_ROOT} is a workspace folder by default.

Che-Theia handles settings.json in any workspace folder, so everything works here the same as in VS Code. We don't care what folder the user has opened as a workspace folder.

For a multi-root workspace it's expected that preferences are stored in workspace config file, like che.theia-workspace.
So, for the case like this the preference is stored to workspace config file /projects/che.theia-workspace and it is available under the Workspace scope of settings, please see eclipse/che-theia#778 (comment)

It works as it should. Any preferences come from a Devfile go to Workspace level. If we need to change that behavior in future then we'll reconsider it.

For the case, like this one a multi-root workspace knows nothing about the preference, as ${CHE_PROJECTS_ROOT} is NOT a workspace folder, so the preference is ignored.

It's some hack. We shouldn't handle it in the context of multi-root work.

I could provided some logic for the multi-root mode and export preferences from ${CHE_PROJECTS_ROOT}/.theia/settings.json to /projects/che.theia-workspace, but for me it makes sense only if it's expected that a user wants to turn on and turn off the multi-root mode for the same workspace.
For this case we have to handle both exports:

• ${CHE_PROJECTS_ROOT}/.theia/settings.json ===> /projects/che.theia-workspace
• /projects/che.theia-workspace ===> ${CHE_PROJECTS_ROOT}/.theia/settings.json

Also we should think about conflicts or just overwrite preferences at switching the multi-root mode - if preferences are not equal.

Absolutely, no need to handle such cases. Switching the multi-/single-root mode is a temporary stage.

Note: As I mentioned above - I don't see any problems and we don't need provide any logic to export preferences for the case like this - it's handled automatically for both modes: multi-root is ON and OFF.

To be honest I'm not sure that it's usual use case for che and expected behavior - if a user creates Go or Java maven multi-root workspace - does the user want to turn off the multi-root mode after a workspace creation?

That's not expected use-case.