Community
Participate
Working Groups
In 20020508 integration driver, I have added an action to the existing help action set that has visible=true (in plugin.xml in org.eclipse.help.ui). The action is: <action id="org.eclipse.help.ui.OpenHelpSearchPage" menubarPath="org.eclipse.search.menu/dialogGroup" label="%openHelpSearchPageAction.label" icon="icons/searchview.gif" class="org.eclipse.help.internal.ui.OpenHelpSearchPageAction"/> The help ui plugin requires search plugin that defines the group. I get the following in the console. Invalid Menu Extension (Path is invalid): org.eclipse.help.ui.OpenHelpSearchPage The action is not visible. If I dissable the action set using customize perspective, and than enable action set again, the action becomes visible. It dissapears again if workbench is restarted.
Please investigate.
The action you added to the help action set (in the help plug-in) refers to a menu path that is defined by the search action set (in the search plug-in). Even though the help plug-in has the search plug-in as a required plug-in, it still does not allow you to "inherit" the menu path defined by the search action set. Action sets must be self-contained and not require another actions set is "on". What is happenning on start-up is the help plug-in action set is processed first (because we order action set contribution based on plug-in id sort order so that menus come up in the same order all the time). It refers to a menu path that does not exist (because the search plug-in action set has not been processed yet). So later when you turn off the help action set (via perspective customize) and turn it on again, it is just lucky the search action set is already on. That is, if you turned both the help and search action sets off, then turned only the help action sets on, you would get the same problem. Anyway, enough rambling. The solution is for the help action set includes the menu definition that the search action set has. That is, it needs at least the following: <menu id="org.eclipse.search.menu" label="%searchMenu.label" path="navigate"> <groupMarker name="dialogGroup"/> </menu> (I did not include the other group marker nor the separator as you are not referencing them in the help action set). The search and help plug-in need to have some agreement now about the menu definition. We actually do something along the same line for the "Run" menu. In 2002-05-15 integration build, you will see both the debug and external tools plug-in have agreed on a common menu definition.
This looks like a bad mechanism to me, it depends on plugin id. If help was following search in alphabet, there would be no immediate problem. I think the UI code should take care of it without me doing anything like you described, especially that search menu was not disabled. I would even agree that if search action set is disabled, my action should not appear at all. 1. You ask me to contribute a menu with id that does not contain my plugin ID. 2. Help should not be required to agree with search on menu definition. Imagine if help was part of another product, not core Eclipse. 3. When I include the menu that you ask me to use, I find that "Help..." appears at the top of the menu above "Search...". That is wrong. I need to add the exact group definitions that search plugin does and uses. Does this means that any plugin added later, that tries to add to the same menu, can completely rearrange or rename the menu? Would not it be better if workbench processes menus first, independent of whether action set is enabled or not. Then all the actions from enabled action sets could be added. You could still do the same sorting as now, but not let it affect you when building menus. If at the end a menu is not empty it can be displayed. If what I am writing does not make any sense, and you think current behavior of action processing is desirable, resolve the bug (invalid) again. Thanks.
The issues you raise above are all correct. We need to do something here, but cannot for v2. Defering to v3.
The problem also affect Search-Java... menu. It is not displayed when it should be in Java perspective. After it is dissabled and enabled it shows up. I have also got to the state when after restaring Eclispe got bunch of errors about java actions similar to Invalid Menu Extension (Path is invalid): org.eclipse.help.ui.OpenHelpSearchPage what I got regarding help action.
*** Bug 16228 has been marked as a duplicate of this bug. ***
Konrad, By adding the menu element to your action set, does it fix your problem? Is that an acceptable workaround for now. This is not something we can fix for 2.0 unless it becomes a stop-ship problem.
I have added the menu element, and it looks like everything is working all right. I have not encountered problems with solution yet.
re-opened for investigation
*** Bug 14541 has been marked as a duplicate of this bug. ***
Reducing to P3 as there is a workaround
In 3.0 Help does not contribute Search->Help action anymore, so case of help cannot be used to reproduce the problem in out of the box Eclipse. You may keep the bug open to keep track of the underlying problem.
Although Help doesn't suffer from the problem described in this PR (and dups and dependent PRs) any more, the problem still causes trouble when people want to contribute to menus that are defined in other plugins. We should find a durable solution here.
Moving Dougs bugs
At least part of this will be addressed in the new work ... all menu contributions within a menu are ordered before being applied, so you can contribute to a menu from another plugin. PW
The new menuContribution/org.eclipse.ui.menus story does support contributing to any IDed menu from any plugin. But it does not have enough adoption to close this bug yet. PW
*** Bug 83006 has been marked as a duplicate of this bug. ***
I second Paul's observation: https://bugs.eclipse.org/bugs/show_bug.cgi?id=15670#c17 Where does the 'Invalid Menu Extension (Path is invalid):' error come from? Is there some place else where the menu system is documented for troubleshooting purposes? I'm running into a similar problem with a plugin that I need to split into multiple parts that contribute actions to the same menu. This ought be a very simple thing to do. I'm amazed how complicated these "simple" things can get.
Created attachment 75898 [details] 2 bare-bones plugins with a common menu
(In reply to comment #19) > I'm running into a similar problem with a plugin that I need to split into > multiple parts that contribute actions to the same menu. This ought be a very > simple thing to do. I'm amazed how complicated these "simple" things can get. You need to replicate your actionSet menu structure in as many actionSets that contribute to that menu. You're missing one of the groups in one of your actionSet definitions. PW
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
While trying to contribute to the JDT/UI's "Source" menu, I see the exact problem discussed here. In the debugger I can clearly see a loop over 20 PluginActionSets where processing element #6 requires element #8 to be processed before. To see it just set a breakpoint on the second return in org.eclipse.ui.internal.PluginActionBuilder.BasicContribution .contributeMenuAction(ActionDescriptor, IMenuManager, boolean) (The exact order of action sets seems to depend on what views were open when the workbench was closed.) Assuming that the list of 20 action sets might be complete, I could see an almost straight-forward way of fixing this issue (even before its 8th anniversary ;-) Am I missing something? Would you like me to draft a patch?
(In reply to comment #23) > Assuming that the list of 20 action sets might be complete, > I could see an almost straight-forward way of fixing this issue > (even before its 8th anniversary ;-) > > Am I missing something? Action set order is determined by the plugin id to provide stability to menu items (i.e. you can't have menu items hopping around all over the place). Any fix you consider has to maintain that order (specifically the order of the contributed menu items and cascading menus). Also keep in mind that this component is in maintenance mode, so any fix would have to include a fairly comprehensive test (I can help with some ideas). Commands, Handlers, and Menu Contributions support is written to allow contributions to depend on other contributions, and should be preferred over actionSets if at all possible. PW
Created attachment 146691 [details] sketch of a patch This is roughly what I had in mind: surround the registration loop for action sets with a simple retry mechanism. It's not at all safe yet, just to get some feedback whether you consider this approach worthwhile. > Action set order is determined by the plugin id to provide stability to menu > items (i.e. you can't have menu items hopping around all over the place). > > Any fix you consider has to maintain that order (specifically the order of the > contributed menu items and cascading menus). that's maintained, I believe. > Also keep in mind that this component is in maintenance mode, I didn't know about that. Does the engine need some fresh oil? ;-) Is that related to e4? > so any fix would > have to include a fairly comprehensive test (I can help with some ideas). Help on writing tests I would need, indeed. I'll just attach the simple plugin I used for trying the patch. > Commands, Handlers, and Menu Contributions support is written to allow > contributions to depend on other contributions, and should be preferred over > actionSets if at all possible. Yup, that assumes, the menu group you contribute to, is a Menu Contribution to begin with, right?
Created attachment 146695 [details] Simple sample plugin This simple plugin fails without the patch and works with it. (it contributes an action to the "Source" menu into "importGroup"). Switch to Java Perspective to see the action.
Would someone care to comment on my patch in comment 25? Thanks
I won't have time to look at this in M5, but I will commit to looking at this in M6. PW
(In reply to comment #25) > > Yup, that assumes, the menu group you contribute to, is a Menu Contribution > to begin with, right? Meaning if you want something to work different than the way actionSets work today (and actionSet have never been able to contribute to other actionSets) then you should use menuContributions, not actionSets. PW
(In reply to comment #25) > Created an attachment (id=146691) [details] > sketch of a patch Comments on the patch: 1) I think you've hit on the correct place to tackle this problem for actionSets minor niggles: 2) I'd try a LinkedList instead of an array list, since you'll be adding and removing from the ends 3) When you log about "Unmet dependencies" I would expose a method like PluginActionBuilder.ideLog(IStatus) so that it wouldn't be logged under the same situations as the code that was in PluginActionBuilder 4) we used to log more specific information so that you could tell which actionSet and/or action was failing ... is that info still available in this case? behaviour: 5) Your loop will fail on the first unmet dependency, it won't process 3 and throw away 2, for example. I'm on the fence about this, solving it makes the processing loop more complicated. See org.eclipse.ui.internal.menus.WorkbenchMenuService.addContributionsToManager(IServiceLocator, Set, ContributionManager, String, boolean, List) and the unfortunate retryList risks: I'm concerned a little about performance, especially if this can be run on a perspective switch. Dynamic plugins is perhaps the biggest risk. We'd need a couple of tests showing what happens if Plugin B actionSet depends on plugin A actionSet, and Plugin A is uninstalled. It's acceptable if the dependents disappears, but not if the system yacks and errors all over the place or leaks those actionSets for plugin A (that would potentially leak class loaders). I'd like to see a number of the different actionSet test cases added as well (1 dependency, 2 dependencies from one actionSet, multiple actionSets that depend on one actionSet, 5 dependencies where 3 are met and 2 are not, etc). Dynamic tests are added in org.eclipse.ui.tests.dynamicplugins like org.eclipse.ui.tests.dynamicplugins.ActionSetTests (but you might need a new one or 2, plus 2 new dynamic plugins). General tests for some of the scenarios would be added in tests similar to org.eclipse.ui.tests.api.IWorkbenchPageTest or org.eclipse.ui.tests.api.IWorkbenchWindowActionDelegateTest PW
