Community
Participate
Working Groups
Build 20020515 Due to the conversion to the new menu structure JDT ended up having four actions sets named org.eclipse.jdt.ui.OpenActionSet, org.eclipse.jdt.ui.JavaActionSet, org.eclipse.jdt.ui.CodingActionSet and org.eclipse.jdt.ui.SearchActionSet. In the navigate menu we want to create the following order: OpenActionSet CodingActionSet JavaActionSet. The only way to do that is to name the OpenActionSet A_OpenActionSet. This lets us look stupid. Any other idea ?
The order should be based on id comparision, not name comparison. So we will only look stupid to developers, not end users.
Let me know if this is critical for 2.0.
Yes, we don't look stupid for the user, only for developers using JDT. I am only asking since we define these constants as API. It is not critical for 2.0 since we have a workaround.
Deferring then.
Reopen for investigation
We should look at adding order numbers to action sets and possibly other kinds of contributions. A simple "order" attribute on the action set would suffice. E.g. if action set A has order=10, and action set B has order=5, then B appears before A regardless of the order of their ids. Action sets with no order number, should still get ordered by id, after any ones with a specific order number. This could also be used to break ties between action sets having the same order number. This order also has to be stable independent of incremental changes to the perspective (see bug 18357).
Should use float for order numbers.
Were you actually seeing the order change by adding the "A_" prefix to the action set id? The registry readers only sort on plugin ids, not action set ids. Once the IConfigurationElement(s) are sorted by plugin id, we read the action sets entries for each IConfigurationElement, in no special order (ie what ever order the IConfigurationElement returns them in). Nevertheless, we still have an ordering problem when action sets are added/removed from the visible list.
Sorry, I spoke (wrote?) too soon... There is a snippet of code that will order plugin action set contributions based on their ids.
Not going to be fixed for 2.1 M4 We would like to address the real problem which is allowing developers better control of the order of each action. The solution should also keep in mind possible future features like user customizing where an action lives in the menu/tool bars.
Should also take plugin prerequisites into account in order, if an explicit ordering is not given. See bug 36929 for more context.
*** Bug 75229 has been marked as a duplicate of this bug. ***
Bug 71710#6 contains steps to reproduce the use of different menu definitions based on different activation sequences.
Related words from Dirk: IMO there are two different issues here: 1.) the ordering problem 2.) the pricipal need of a menu redefinition. If plug-in B requires plug-in A which defines a menu M and B wants to contribute to that menu M there shouldn't be any need for B to redefine the menu M. It should only add actions or additional groups. Regarding the steps I mentioned see bug 71710 comment 6. There both search and junit plug-in defines the same search menu but depending on some activation sequence either the menu from search or the one from junit is taken. I had similar problems with the Refactoring & Source when I tried to move the menu definition of the refactoring menu down to LTK. Depedining on the activation squence the order was either Refactoring Source or Source Refactoring.
I'm running into issue #2 of this bug: 2.) the pricipal need of a menu redefinition. If plug-in B requires plug-in A which defines a menu M and B wants to contribute to that menu M there shouldn't be any need for B to redefine the menu M. It should only add actions or additional groups. I have a core plugin declaring a base menu to which I want to add stuff from other plugins with require my core plugin, but the menu creation in these sub-plugins is failing because the core plugin has not created the menu yet. I'm unclear on the status of this bug. Is is possible to reliably "trick" the platform into loading the actionSets in a particular order by strategically naming them, or is there no workaround for this behaviour?
I just found bug #15670, and I now see that the alphabetical order dependency is on on the plugin id, not the actionSet id. I also found the workaround of essentially recreating the menu in each plugin, and that seems to work. Kinda messy though.
This bug reads like the same problem I'm having with my plug-in in 3.1, but I'm not sure ... can anyone familiar with this bug let me know? I have the following section in my plugin.xml: <extension point="org.eclipse.ui.popupMenus"> <objectContribution objectClass="org.eclipse.jdt.core.IType" id="com.einstruction.eclipse.plugin.cpsassist.contribution1"> <menu label="eI" path="additions" id="com.einstruction.eclipse.plugin.menu"> <separator name="group1"> </separator> </menu> <action class="com.einstruction.eclipse.plugin.cpsassist.UnitTest" enablesFor="1" id="com.einstruction.eclipse.plugin.cpsassist.unittest" label="Open Unit Test Class" menubarPath="com.einstruction.eclipse.plugin.menu/group1"/> <action label="Update Mock" class="com.einstruction.eclipse.plugin.cpsassist.UpdateMock" menubarPath="com.einstruction.eclipse.plugin.menu/group1" enablesFor="1" id="com.einstruction.eclipse.plugin.cpsassist.updatemock"> </action> </objectContribution> </extension> ... and I can't figure out a way to control the order of the two actions as the appear in the context menu. I even re-structured the actions so that each action was in its own objectContribution tag, and still I couldn't control the order. I resorted to the following, which is less than ideal because each item is now in its own group, with a separator in between. <extension point="org.eclipse.ui.popupMenus"> <objectContribution objectClass="org.eclipse.jdt.core.IType" id="com.einstruction.eclipse.plugin.cpsassist.contribution1"> <menu label="eI" path="additions" id="com.einstruction.eclipse.plugin.menu"> <separator name="group1"> </separator> <separator name="group2"> </separator> </menu> <action class="com.einstruction.eclipse.plugin.cpsassist.UnitTest" enablesFor="1" id="com.einstruction.eclipse.plugin.cpsassist.unittest" label="Open Unit Test Class" menubarPath="com.einstruction.eclipse.plugin.menu/group1"/> </objectContribution> <objectContribution adaptable="false" id="com.einstruction.eclipse.plugin.cpsassist.contribution2" objectClass="org.eclipse.jdt.core.IType"> <action label="Update Mock" class="com.einstruction.eclipse.plugin.cpsassist.UpdateMock" menubarPath="com.einstruction.eclipse.plugin.menu/group2" enablesFor="1" id="com.einstruction.eclipse.plugin.cpsassist.updatemock"> </action> </objectContribution> </extension>
Moving Dougs bugs
*** Bug 152457 has been marked as a duplicate of this bug. ***
I just wasted hours trying to figure out why an antecedent plugin could contribute to a dependent plugin menu, but not the other way around. Then I found that the RegistryReader compares by plugin id and not by the plugin dependency hierarchy! Here's the comment from the orderExtensions method: // By default, the order is based on plugin id sorted // in ascending order. The order for a plugin providing // more than one extension for an extension point is // dependent in the order listed in the XML file. I can't figure out how this bug can be considered an "enhancement", this is broken behavior. I should not have to rename my plugin id to something that starts with a z to make sure its extensions are read last so all of the menus it depends on are initialized first. In my opinion, this bug is P2/Normal.
You can't contribute to the menu from one action set to another (well you can, but we won't do it correctly). From the extension point description: "There is an implementation limitation which currently affects action sets. It is important to define the entire menu structure that is to be referenced within the action set. So, for example, if another action set defines a menu called "example", it is not possible to rely on "example" existing. It is necessary to redefine the "example" menu in every action set that wishes to use it." However, there is work on the org.eclipse.ui.menus extension point, see bug 154130 As part of defining menus through org.eclipse.ui.menus, you will be able to reference existing menus defined in other plugins regardless of "plugin order", and with IDs you will be able to order contributions. PW
(In reply to comment #21) > You can't contribute to the menu from one action set to another Is that true? What is it called when plug-ins contribute to the edit menu or the top-level menu? I didn't see any examples redefining /those/ menus to contribute to them.
(In reply to comment #22) > (In reply to comment #21) > > You can't contribute to the menu from one action set to another > > Is that true? What is it called when plug-ins contribute to the edit menu or > the top-level menu? I didn't see any examples redefining /those/ menus to > contribute to them. Those menu entries are not contained in action sets PW
Assigning to component owner PW
These will not be worked on. Please re-open if you feel the community should get a crack at them.
