Community
Participate
Working Groups
Build Identifier: M20090211-1700 I have a plugin and several fragments for my plugin. These fragments are intended to be delivered to different end users, separately in most cases. The plugin contributes menu items that I want to be available to all fragments, and the fragments contribute menu items that apply to only that fragment. However, some of these fragment-specific menu items are the same across fragments, and since sometimes these fragments are delivered together, we get duplicate menu items when really we just want one. In case I have not explained clearly enough, here is an example structure: MyPlugin - MyFragmentA - Contributes MenuItemA to 'File' menu - Contributes MenuItemB to 'File' menu - MyFragmentB - Contributes MenuItemA to 'File' menu - Contributes MenuItemC to 'File' menu If I deliver the two plugins together, I get this: - MenuItemA - MenuItemA - MenuItemB - MenuItemC When what I want is this: - MenuItemA - MenuItemB - MenuItemC Note that the implementation of each action is the same for each fragment, except for the icon file's path. I am not sure whether this is intended behavior, but I also can't think of any reason why two actions with the same id, class, and path should ever be duplicated, even if listed twice in plugins. Maybe I am misusing the framework? I'm guessing, however, that's it's a minor deficiency. Reproducible: Always Steps to Reproduce: N/A
And which one should win? The first one loaded? This would lead to strange behavior because for Customer A it will show the icon from "Fragment A" and for Customer B the one from "Fragment B" (the order is random and defined by the order Equinox resolves the plugin.xml).
In my case the icons are the same, the paths are only different because they are delivered with the fragments (I believe this is because they cannot refer to icons in the plugin). Alternatively, having different icons for the same contribution isn't something I would expect anyone to do. We could consider whether different versions of the same plugin might create this situation, but I think p2 prevents that from happening. It would probably be fine to just choose whichever is discovered first, as long as the other important fields are equal (id, class, menu path, etc.).
Because in the case of menus IDs are not unique (this is a legacy requirement) we have no way of guessing which menu item to pick. If the objects were truly equal we could only add one, but even in your case that's not true. You are acting as an aggregator for multiple functionality, it sounds like you are using fragments to deliver slightly different product configurations. I think you have 2 choices: 1) if MenuItemA is common to your 2 fragments, include it from a common fragment. 2) in fragmentB, add a visibleWhen that checks to see if fragmentA is installed so you can be not visible. See http://wiki.eclipse.org/Command_Core_Expressions#Property_Testers Once the system is running, the system doesn't usually know which Extension comes from which fragment. They live in the host bundle namespace and host bundle classpath. PW
What do you mean by "in the case of menus IDs are not unique"? The action set ID? The action ID? Some other ID I might not be aware of?
(In reply to comment #4) > The action set ID? The action ID? Some other ID I might not be aware of? The contribution ID (which most times, but not always, is the action ID). Most SWT menu items are rendered by a matching IContributionItem. In the case of IActions, when placed in the menu we create the matching ActionContributionItem. When you start looking at the MenuManager it will have a set of IContributionItems where any number of them can have the same ID. PW
I'm trying to understand what you're saying but the lack of subject knowledge is a significant barrier. You said that if they were truly equal it would make sense to just add one. What about this situation? ContributionC (in fragment A) ID: com.company.functionC class: com.company1.ClassA (in host plugin) icon path: /icons/iconA.png (in fragment A) menu path: /com/company/additions ContributionC (in fragment B) ID: com.company.functionC class: com.company1.ClassA (in host plugin) icon path: /icons/iconA.png (in fragment B) menu path: /com/company/additions Would they be considered identical in this case, even though the icons are technically separate files? Or would you have to do the comparison later on, when the icons have been loaded and the IDs may not be unique any more?
Sorry, that should be: ContributionC (in fragment A) ID: com.company.functionC class: com.company.ClassC (in host plugin) icon path: /icons/iconC.png (in fragment A) menu path: /com/company/additions ContributionC (in fragment B) ID: com.company.functionC class: com.company.ClassC (in host plugin) icon path: /icons/iconC.png (in fragment B) menu path: /com/company/additions
(In reply to comment #7) > ContributionC (in fragment A) > ID: com.company.functionC > class: com.company.ClassC (in host plugin) > icon path: /icons/iconC.png (in fragment A) > menu path: /com/company/additions > > ContributionC (in fragment B) > ID: com.company.functionC > class: com.company.ClassC (in host plugin) > icon path: /icons/iconC.png (in fragment B) > menu path: /com/company/additions The problem is we don't see /icons/iconC.png, instead we see something like: bundleentry://34//icons/iconC.png and bundleentry://182//icons/iconC.png We can merge menus that seem to come from separate contributions (most of the time) but not these actions, as they're different. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
