Community
Participate
Working Groups
Created attachment 229482 [details] Screenshot or Plugin Registry View I've just spent a whole evening debugging my Capability Definitions because the entire "Team" contextmenu was hidden on any project when egit was disabled by Capability. I finally found out that egit overrides the "Team" ObjectContribution with its own "Team" menuContribution (see attached screenshot). I've found a fix for my original problem, which I will also deploy to the EPP Cleassic package, but still I'm wondering why egit overrides the org.eclipse.team.ui declaration of the "Team" contextmenu ? Shouldn't there be one canonical definition of the parent menu only ?
Created attachment 229483 [details] Screenshot of egit duplication in Plugin Registry View
It is not absolutely necessary to redefine the menu, but it does not hurt. However, EGit must use at least the same IDs. I don't see a real problem here. Suggest to close as WORKSFORME.
The problem for me was that the "obvious" capability definition: <activityPatternBinding activityId="org.eclipse.team.egit" pattern="org\.eclipse\.egit\.ui/.*"> </activityPatternBinding> ended up hiding too much (ie the Team support was unusable for any other team providers like Subclipse, CVS or clearcase). The fix was this capability definition: <activityPatternBinding activityId="org.eclipse.team.egit" pattern="org\.eclipse\.egit\.ui/org.*"> </activityPatternBinding> which works for me. I have no strong opinion about keeping or getting rid of the extra menuContribution ... I'm just surprised and wondering why it's there. Given that o.e.egit.ui depends on o.e.team.ui it will always have the team.ui popupMenu contribution visible. None of the other CM integrations that I've seen redefine the "Team" menu so why does egit ? Are we sure that the redefinition can't ever hurt ?
(In reply to comment #3) > Given that o.e.egit.ui depends on o.e.team.ui it will always have the > team.ui popupMenu contribution visible. None of the other CM integrations > that I've seen redefine the "Team" menu so why does egit ? Are we sure that > the redefinition can't ever hurt ? Well, it hurt you ;-). Having said that, removing the menu redefinition will probably not be that easy, because EGit currently uses the old and the new approach to contribute the context menu. I quickly tried to remove the menu and change the location URI to "popup:org.eclipse.ui.popup.any?after=team.main/group1" but that does not seem to work. Maybe Paul has a better idea?
Ok, if Egit depends on the "new way of contributing menus" that's a very good reason to keep things they are. I'm still interested in understanding the "why" in more detail, but wouldn't insist on changing the code here. Would it make sense to add the "menuContribution:team.main" into the o.e.team.ui plugin, such that any consumer can use either the old or the new way contributing menus?
(In reply to comment #4) > Well, it hurt you ;-). Having said that, removing the menu redefinition will > probably not be that easy, because EGit currently uses the old and the new > approach to contribute the context menu. When mixing menu contributions, that's the suggested approach. org.eclipse.ui.menus should define a menu with the same ID and the same group markers/separators. o.e.ui.menus contributions are merged together, and are also visible to (depending on their location) any o.e.ui.popupMenus or o.e.ui.actionSets contributions that come along. > > I quickly tried to remove the menu and change the location URI to > "popup:org.eclipse.ui.popup.any?after=team.main/group1" > but that does not seem to work. Background: Our system builds menus 1) programmatic contributions, like a view using IActionBars or the ActionAdvisor for a workbench window, 2) org.eclipse.ui.menus contributions are applied, and then 3) the legacy action contributions are applied (actionSets, popupMenus, editorActions, viewActions, etc) So to contribute to a well defined menu in the platform that uses legacy action extensions, they have to redefine it in o.e.ui.menus. (In reply to comment #5) > > Would it make sense to add the "menuContribution:team.main" into the > o.e.team.ui plugin, such that any consumer can use either the old or the new > way contributing menus? It would be nice for team to define its menu using o.e.ui.menus even if it keeps all of the existing objectContributions but general action->command conversions are only happening in active development areas. There's nothing wrong with opening a bug about if there isn't one open already. PW
So I understand 1. There's nothing wrong in egit - they _have to_ redefine their menu to leverage new style contributions; 2. It makes sense to convert the "Team" toplevel menu from popupMenu to o.e.ui.menus in o.e.team.ui 3. This conversion is without any risk since all legacy contributions can leverage the new-style parent just like the old-style parent. If you can confirm these, I can create a patch for o.e.ui.team that can be easily pulled. I'm also moving this bug from egit into o.e.ui.team since there's nothing wrong in egit - it's just the way it has to be. In order to address my immediate problem, I'm requesting Egit to publish a capability defintion as per https://bugs.eclipse.org/bugs/show_bug.cgi?id=405520 . Moving the bug to team.ui for updating the "Team" menu definition.
(In reply to comment #7) > So I understand > > 1. There's nothing wrong in egit - they _have to_ redefine their menu to > leverage new style contributions; > > 2. It makes sense to convert the "Team" toplevel menu from popupMenu to > o.e.ui.menus in o.e.team.ui > > 3. This conversion is without any risk since all legacy contributions can > leverage the new-style parent just like the old-style parent. Yes, this is correct PW
Bug 480557 may be related.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
