Community
Participate
Working Groups
The core team is about to offer support to change the workspace dynamically. The envisionned solution without the new runtime is to return a special exit code and do something special to restart. However, with the dynamicity and the new runtime we should able to do better. Any thoughts are welcome.
A couple of things to note/remember. - the workspace is not just for resources. It is the data area for plugins (I don;t mean the metadata but rather plugins are free to discover the locaiton of the workspace and write whatever user files they want there. Or not. - not all scenarios require/want a workspace. Various RCP scenarios explicitly don't want one because they have nothing to put there. - changing the workspace is something for which plugins need to be prepared. Assuming the workspace contains resources, various plugins could have resource objects. This are implicitly specific to a particular workspace. When the workspace is changed, these handles must be invalidated. Suggestions: - add lifecycle (where?) to say that the workspace is/has changing/ed. Interested plugins would listen and do the right thing. - plugins which use the workspace but do not listen are either legacy or misbehaving. The only reasonable way to handle them is to restart them. - plugins must explicitly declare that they are able to handle dynamic workspaces. When the workspace is changed, dynamic enabled plugins are notified. Non-enabled plugins are restarted.
Unclear if this effort is still going forward. Will leave open pending discussions with the Core team
Old summary: Changing workspace while running
*** This bug has been marked as a duplicate of 5509 ***
