| Summary: | Switching workspaces | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | Incubator | Assignee: | Jeff McAffer <jeffmcaffer> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dj.houghton, jpshack |
| Version: | unspecified | ||
| Target Milestone: | 3.0 M9 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Pascal Rapicault
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 |