My scenario involved the same series of steps but with a maven project (vs a gradle project) in a 2 (or more) application dashboard.

@TrevCraw , I did notice that when following the steps above, specifically in the 5th step, manual additing of project, the workspace is not specified. In this step, I observed that the workspace name appears as 'UNTITLED'. Upon further investigation during debugging, I discovered that manually adding a project to the Liberty dashboard requires a 'workspaceState' and utilizes a specific type of key variable, 'LIBERTY_DASHBOARD_WORKSPACE_STORAGE_KEY', to fetch the workspace accurately. Since no workspace is created beforehand, there is no workspace data available at this point. Consequently, the process only considers the ProjectProvider 'projects' and excludes the manually added project.

The same kind of event occurs when selecting File -> Save Workspace As... ,
For example, if we have a workspace with manually added projects, and then attempt to use File -> Save Workspace As..., a new workspace is created. Consequently, the new workspace does not include the manually added projects from the previous workspace. Therefore, I hope that there is an association between manually adding projects and workspaces.

The above is the case for the initial attempt when we perform all the steps mentioned above.

In subsequent attempts to remove or add the project, the current workspace state contains dashboard data fetched from the context. This data have all manually added projects in the dashboard, in that particular workspace, as it reflects the manually added project in the Liberty dashboard during subsequent attempts.

When I checked Microsoft Visual Studio Code.
In their code, I observed that when performing a "Save untitled workspace," they pass the untitled workspaceIdentifier and the newWorkspacePath, creating a newWorkspaceIdentifier, and finally delete the untitled workspaceIdentifier. This results in a change in the workspace state.

https://github.com/microsoft/vscode/blob/main/src/vs/workbench/services/workspaces/electron-sandbox/workspaceEditingService.ts

Check the possibility of saving the workspace state before performing a Save untitled workspace, so that we can retrieve it once the IDE is reopened. There have been no changes made in a branch, so I am not attaching that.

Though debugging found that the issue happens due to an unsaved workspace , when you add the project to the liberty dashboard manually before saving the workspace and then upon saving the workspace at the end as per the steps in the issue, the state is not saved.

After following the steps in the issue and when tried to get the data about the manually added projects, the data is empty , however when the workspace is saved first, then the data for the manually added projects is available .

Tried saving the workspace first followed by the steps in the issue and the issue doesn’t occur .

Hi @JoshwinThomasIBM ,

Based on the high level description of the problem, I think there are two different approaches we can take:

1. LTV should know the projects that were manually added during a user session. In the case where there is an unsaved workspace, instead of saving a "manually added" project to the unsaved workspace when the project is added, we should see if there is a way to save the "manually added" project(s) when the workspace is saved. When VS Code asks the user if they want to save the workspace, can LTV hook into that flow? Once a user saves the workspace, can we then add the "manually added" project(s) to the newly saved workspace as part of that save flow?
2. When users manually add a project to the LTV dashboard for the first time, LTV can inform them that they must save their workspace in order for the added project to appear in the dashboard in future VS Code sessions. If they agree, we invoke the VS Code flow to save the workspace. After the workspace is saved, we then add the "manually added" project to the newly saved workspace.

Option 1 is less intrusive, but I am not sure if it is possible. You will need to investigate.
Option 2 seems to be simpler from a coding perspective (not sure what is possible in this case either), but provides more steps for the user. Once again, you will need to investigate.

I am open to other ideas as well. If you have any suggestions you would like to propose, please do.

Discussed with @mrglavas and @turkeylurkey:

• If we go with option 1, we should confirm that VS Code always prompts users to save the workspace when they close the workspace and when they close the IDE.
• For option 2, when we prompt the user to save, we should provide a button to save the VS Code workspace as part of the message presented to the user.

There are two ways in which we can close the workspace :

1 - by closing the IDE and we get a prompt for asking to save the workspace , we could get a control over this flow in the
deactivate() method in extension.ts ( when we close the IDE the extension is deactivated always and deactivate()
is called ).

2 - File-> closeWorkspace - in this flow we could not get the control over closing the workspace , deactivate() is not called
here since we are only closing the workspace and IDE is still open and the extension is not deactivated.
Seems like there are no direct api's available to hook into the flow for the 2nd case

Moved ahead with prompting the user to save the workspace first when a user try to add a project to the liberty dashboard where the workspace is untitled and contains more than one project. Changes are completed and is in for review and demo