Community
Participate
Working Groups
I had thought that sharing workspaces between products with different plugin sets was not supported due to the errors that occur when you do so. However I was told that my assupmtion was incorrect. So this bug is to track that issue with Views and Perspectives which I assume are the province of the UI. These were using JDK1.3.1 on WSAD based on eclipse 2.0 M5. I bring up WSAD and open several WSAD projects with an assortment of WSAD specfic views and perspectives. Then I shut down WSAD. Now the following: 1) Launch the base eclipse M5 against the same workspace and I have to wade through a *set of error dialogs* about views and perspectives that have gone missing. When eclipse finally comes the initial perspective is a Navigator view and the other perspectives are still there but seem to be reset to a default "Resource" Perspective. 2) I haven't yet tried this (am in the middle of setting it up features for WSAD) but it is possible to unconfigure a feature in the update manager so that the next time you launch the workbench they don't exist which would give the same error as in 1 above I think. I append the results of that as soon as I know. Currently we are on a path of recommending users not to share a workpsace among different eclipse based products like WSAD because of these errors.
Using integration build 502 you can use the update manager and the base eclipse to see the behaviour described in 2 above. 1.Launch eclipse open several perspectives JDT and PDE based ones. 2. Open the update manager perspective. An expand current configuration until you see the JDT and PDE feaures. 3. Select the PDE and Unconfigure. Hit cancel on the question to restart 4. Select the JDT and Unconfigure. 5. If you restart now Eclipse restarts itself but comes up with no errors as it is in the Install/Update perspective. Switch to the previously opened JDT and PDE perspectives and in you'll begin to get several error dialogs.
When migrating from Eclipse 1.0 to 2.0, we now delete the workbench.xml (with warning, and opportunity to cancel), forcing a clean slate in the UI. However, the update scenario you outline is still problematic.
We should try to handle these errors better, or at least collect them and present a single dialog.
We also have a dependency on this being fixed. As a general statement all extension points need to be behave properly under uninstall (John K. claimed this was the case already?).
Needed for 2.0.1.
Change restoreState to return IStatus (MultiStatu) and collected them in a single dialog. Released in the HEAD stream.
Released in the 201 stream as well.
Fix released in both streams (201 and HEAD). All errors are collected in one single dialog.
*** Bug 13690 has been marked as a duplicate of this bug. ***
