Community
Participate
Working Groups
Build 20011206 In EC post: "Caching when using PDE", Chemi writes: This is a suggestion/comment about an annoying situation I have faced twice times already developing/testing plugins within PDE. Well, I execute the plugin selecting plugin.xml file and pressing Run -> Run-time Workbench, which starts a new Eclipse instance. The workspace of this new instance is a directory called runtime-workspace. And at the end of the execution it saves the .metadata directory where many things are cached. For example, Help system and Window Menus. So the problem is that when I am developing a new pluging I execute it many times for testing purposes and I have to be aware of this caching. For instance, any change in a Help pluging won't be shown, and any change in an ActionSet plugin adding a new menu won't be show too. To be able to be sure that I see the last state of the plugin I have to delete that .metada directory each time (I know that for example, for the Help system I can change the version of the plugin and it is refreshed). But, what I think is that PDE should have a propertie where I am able to enable/disable the save of the .metadata directory when I am testing plugins. So I have not to tale care about deleting, renaming or what ever I need to do to avoid caching. Does it make sense for you? ------ To reproduce: - create a self-hosting workspace - launch it once, and exit the target - create a new PDE project Test - replace its plugin.xml with: <?xml version="1.0" encoding="UTF-8"?> <!-- File written by PDE 1.0 --> <plugin id="Test" name="Test" version="1.0.0"> <requires> <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.core.resources"/> </requires> <runtime> <library name="Test.jar"/> </runtime> <extension point="org.eclipse.ui.views"> <category name="Games" id="es.org.chemi.games.category"> </category> <view name="Minesweeper" icon="icons/minesweeper.gif" category="es.org.chemi.games.category" class="es.org.chemi.games.minesweeper.views.MainView" id="es.org.chemi.games.minesweeper.views.MainView"> </view> </extension> <extension point="org.eclipse.ui.actionSets"> <actionSet label="Minesweeper Actions" visible="true" id="es.org.chemi.games.minesweeper.actionSet"> <menu label="&Games" id="es.org.chemi.games.minesweeper.menu"> <separator name="es.org.chemi.games.minesweeper.separator"/> </menu> <action label="&Minesweeper" icon="icons/minesweeper.gif" class="es.org.chemi.games.minesweeper.actions.WorkbenchWindowActionDeleg ate" menubarPath="es.org.chemi.games.minesweeper.menu/separator" id="es.org.chemi.games.minesweeper.action"> </action> </actionSet> </extension> </plugin> - launch the target again - the menu does not show up - delete the .metadata for the target workspace (not the dev workspace) - try again - this time it appears. A workaround is to choose Perspective / Customize... and check the MineSweeper Actions item under Other.
Tod, pls try this in the latest 2.0 builds.
This is still an issue in 20020502.
See Perspective.save/restoreState(....)
Understand the confusion, but it is working as designed (right or wrong). The 2.1 PDE launch option of clear workspace is a heavyweight resolution (you loose projects too). I'm about to enter a request the PDE launcher add a "clear .log" option, so you can easily tell if you have new errors during a test cycle. Maybe there is room for a similar request to reset the workspace .metadata, or maybe just zapping the workbench.xml file would be enough?
Yes, deleting the workbench.xml would suffice. However, we're going to have to do better for R3.0 to support dynamic plugins. The UI should update appropriately when extensions come and go, or change (whether dynamically or not).
*** Bug 36107 has been marked as a duplicate of this bug. ***
*** Bug 60071 has been marked as a duplicate of this bug. ***
In the current support for dynamic plugins, if you add this plugin dynamically, you will be prompted to reset the current perspective (because you are adding something new to the menubar). If you respond "yes" and reset the perspective, the new menubar entry appears. Bug 61162 suggests this is a bit harsh. Watch bug 61162 for a more elegant solution. The original problem, however, still exists. If you reset the perspective, the new menubar entry will appear. Better than the original workaround suggested.
Can we also address the non-dynamic plugin case for 3.0? - user shuts down - installs a new plugin adding some always-on action sets, or action sets associated with open perspectives - user restarts
The always-on case is the more important of the two.
Fix released to HEAD (class perspective).
Need to handle the case where the user manually turns off an action set. It should not override the user's choice. For example, the following currently happens: - new workspace - Window > Customize Perspective > Commands - uncheck the Help item - Help > Help Contents is removed from the menu - OK - restart - Help > Help Contents reappears But since the Help action set was previously known to the perspective, it should not be re-added. Suggest moving the new logic later in restoreState, after the perspective state is fully restored from the memento, and checking the alwaysOffActionSets list too.
The following invariants should be maintained: - an always-on action set (which has not been turned off) is in visibleActionSets and alwaysOnActionSets - an action set added via actionSetPartAssociations (which has not been turned off ) is in visibleActionSets but not alwaysOnActionSets - an action set that has been turned off by the user is in alwaysOffActionSets and not in visibleActionSets or alwaysOnActionSets
It would be nice to also process action sets added to the perspective via perspectiveExtensions. This should be pretty straightforward. See how it's done for the Navigate > Show In items in Perspective.getShowInIdsFromRegistry().
Forgot one invariant: - an action set that has been turned on by the user is in visibleActionSets and alwaysOnActionSets, and not in alwaysOffActionSets Basically the perspective has each action set it knows about in one of three states: always-on, always-off, and part-associated. always-on: in visibleActionSets and alwaysOnActionSets (only) always-off: in alwaysOffActionSets (only) part-associated: in visibleActionSets (only)
*** Bug 63008 has been marked as a duplicate of this bug. ***
This fix has been retracted. Postponing fix until after M9.
This seems to be where the action is so... I follow much of what is being said but still conclude that forcing a reset of the perspective when extensions are added is harsh to the point of making some scenarios untenable (e.g., reset throws away all my customizations and since I don't have a single uncustomized perspective, it would be quite disappointing). The original scenario mentioned in the bug is real and important but ultimately it is a developer problem that can be resolved (as suggested) in the tooling. The user adding new plugins (and thus extensions) while Eclipse is shutdown and while it is running seem like the two key scenarios here.
I concur. We should never reset the perspective automatically on plugin addition/removal, whether dynamic or not, since this loses the user's state. For the dynamic scenarios, it could prompt to reset, but this may not be the policy the app wants. It would be better for the workbench's processing of dynamic addition to do what it can incrementally, and for the cases where it can't update incrementally, just leave the perspective without the new functionality. If the app driving the dynamic update wants a different policy, it can do so.
Yes, doing what you can incrementally (and being able to do that in the common cases) is the key. If there are cases where you can't deferring to someone else to do the reset is cool.
Fixed in HEAD for all cases except one: - add an actionSet in a perspectiveExtension for a perspective that is already open (whether active or not) and the actions in the actionSet won't appear until you reset the perspective
Fixed last outstanding case in HEAD but not for the 4pm build (try I200405272000)
Verified in I20040529 using the following variants: - original test as outlined in the first comment - customize a perspective and remove commands - customize a perspective and add commands - add action set via actionSetPartAssociations - add action set via perspectiveExtension
*** Bug 43097 has been marked as a duplicate of this bug. ***
