Add workspace import support to Eclipse launcher window

[deepika-u]

This PR introduces workspace capability in the Choose Workspace dialog.

Users can now import recent workspaces from a previous Eclipse installation directly from the launcher UI.

Features added:

• Detect recent workspaces from previous Eclipse installations
• Import selected workspaces into the launcher
• Prevent duplicate workspace entries
• Filter and search desired workspaces
• Select/Deselect all on visible workspaces
• Handle empty, invalid, and already-imported workspaces
• Dynamically refresh the Recent Workspaces section after updates via browse button

Additional improvements:

• Simplified and cleaned up workspace refresh logic
• Improved UI consistency after workspace removal/import
• Added validation for invalid or non-existing workspace paths

This change enhances workspace migration usability and improves the overall launcher experience for users moving between Eclipse installations.

Before this pr :

After this pr :

1. When fresh eclipse is installed, the twistee against "Recent Workspaces" will remain closed though empty, when one opens it, it would be like below. Import... is the newly added button ->

2. On clicking Import..., you can browse previous eclipse installation path and browse recently used workspaces in it and import them like this - the desired ones ->

3. When i have already imported some workspaces successfully, i get ->

4. I can still add new workspaces to existing list of "Recent Workspaces" from another installation by clicking Import... again like this ->

5. On saying OK on this window, it returns and merges to the previous list of workspaces already imported ->

6. Select one of the imported workspaces and proceed.

How to test this pr :
step 1 - pick this jar ->
org.eclipse.ui.ide_3.23.100.v20260511-1219.zip
extract this zip file to get a jar, place this jar in the fresh eclipse installation at ..\eclipse\plugins folder.
step 2 - Open this file "..\eclipse\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info", search for "org.eclipse.ui.ide," line and replace the whole line with org.eclipse.ui.ide,3.23.100.v20260511-1219,plugins/org.eclipse.ui.ide_3.23.100.v20260511-1219.jar,4,false

Note : Once done with testing, please revert back to get the original eclipse installation state before you proceed.

I am not sure if this can be tested in a different way easily, but i have tested this way on windows platform.

[vogella]

What about storing the workspaces in user scope scoped by product / application instead of storing them in configuration scope. This way the workspaces for a product would always be the same which I think is the most common use case.

[github-actions]

Test Results

   867 files  ±0     867 suites  ±0   52m 28s ⏱️ - 9m 19s
 7 988 tests ±0   7 745 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 466 runs  ±0  19 811 ✅ ±0  655 💤 ±0  0 ❌ ±0 

Results for commit 979ee98. ± Comparison against base commit b58e3b4.

♻️ This comment has been updated with latest results.

[iloveeclipse]

Interesting idea, but can we please made this feature optional, so the "Import..." is not shown at all (we extend IDEApplication and ChooseWorkspaceDialog) to share as much code as possible with original code and default workspace selection dialog)?

We have Eclipse based application deployed with rpm, so by default installation is read only and all settings are stored on (typically mounted) user home and for a specific application version the path would be something like /home/user/.eclipse/com.verigy.itee.ui.ewcProduct_8_8_2_0__user-bf_20260504_0604_048042b160e2_C_BETA__R__64_user_RHEL9_socbn410__1/

Not only that this path is by default hidden, it is also application version specific, different application versions are installed in parallel and should not share the workspaces used.

"Import..." would casue more troubles in this scenario, so we would want to disable this completely to avoid user errors.

What about storing the workspaces in user scope scoped by product / application instead of storing them in configuration scope.

In our case it would be important to have that "per product / per version" or give a chance to see that the workspace is for a different product version.

Ideally Eclise could automatically detect Eclipse workspaces from "compatible" workspaces. "Compatible" is the key, and it should be possible, similar to org.eclipse.ui.internal.ide.application.IDEApplication.checkValidWorkspace(Shell, URL) to override the "default" strategy.

[deepika-u]

What about storing the workspaces in user scope scoped by product / application instead of storing them in configuration scope. This way the workspaces for a product would always be the same which I think is the most common use case.

Thanks for the feedback, i am exploring this path. If it can be done in user mode, made it optional.
Does anyone has any other inputs or suggestions further? on this thought - please welcome!