Bug 83006 - [Contributions] Menus defined in multiple plugins do not always work (sort order of plugin id)
Summary: [Contributions] Menus defined in multiple plugins do not always work (sort or...
Status: RESOLVED DUPLICATE of bug 15670
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0.1   Edit
Hardware: All All
: P3 normal with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Paul Webster CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-17 14:22 EST by Pat McCarthy CLA
Modified: 2007-06-21 10:37 EDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pat McCarthy CLA 2005-01-17 14:22:36 EST
The Eclipse FAQ 223 discusses complex menus
(http://www.eclipsefaq.org/chris/faq/html/faq223.html).  

They are discussed again in the newsgroup
(http://dev.eclipse.org/newslists/news.eclipse.platform/msg32577.html).

And, if you are careful, you can take the provided example and make it work
across multiple plug-ins (plugin a defines the root menu, and plug-in b defines
the additional submenu options found in the menu target defined by plugin a.

But, if this is done in reverse, where plugin a defines the additions and plugin
b defines the root menu target for those additions you get the classic not found
messages such as:
Invalid Menu Extension (Path is invalid): subMenu
Invalid Menu Extension (Path is invalid): subSubMenu
Invalid Menu Extension (Path is invalid): org.eclipse.sample.SampleAction

The plugin ids involved become the issue, the root menu must be defined in a
plugin id that sorts before the additions (a(root),b(add-ons) ok,
b(root),a(add-ons) bad).

This is an issue in that when a product from company qrs (com.qrs...) has menus
designed to be extended by other companies, it works for company xyz
(com.xyz...) but not company abc (com.abc....).  

Gets trickier in that if you add the addon/extension from company abc and say
apply changes dynamically (no restart) it works, but if you restart it fails.

Workaround is to redundantly define the target menu in the contributing plugin
(abc) so it exists even before the owning plugin (qrs) is processed, but this
may trigger other issues long term (translation of property for menu name and so
on).

Snippets of plugin xml below - current set fail at runtime - change plugin id of
the sub menu contributor to get it to work at runtime. 

Root menu plugin.xml
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
   id="com.ibm.actionset.complex"
   name="Complex Plug-in"
   version="1.0.0"
   provider-name="IBM"
   class="com.ibm.actionset.complex.ComplexPlugin">

   <runtime>
      <library name="complex.jar">
         <export name="*"/>
      </library>
   </runtime>

   <requires>
      <import plugin="org.eclipse.ui"/>
      <import plugin="org.eclipse.core.runtime"/>
   </requires>
   
   <extension
          point="org.eclipse.ui.actionSets">
       <actionSet
             label="Sample Set"
             visible="true"
             id="org.eclipse.sample.actionSet">
          <menu
                label="Top Menu"
                path="additions"
                id="complexMenu">
             <separator
                   name="complexGroup">
             </separator>
          </menu>
          <action
                label="Sample Action Complex"
                icon="icons/sample.gif"
                class="org.eclipse.sample.SampleAction"
                tooltip="Hello, World"
                menubarPath="complexMenu/complexGroup"
                id="org.eclipse.sample.SampleAction">
          </action>
       </actionSet>
   </extension>

</plugin>

Submenu plugin.xml
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
   id="com.ibm.actionset.b.morecomplex"
   name="Morecomplex Plug-in"
   version="1.0.0"
   provider-name="IBM"
   class="com.ibm.actionset.morecomplex.MorecomplexPlugin">

   <runtime>
      <library name="morecomplex.jar">
         <export name="*"/>
      </library>
   </runtime>

   <requires>
      <import plugin="org.eclipse.ui"/>
      <import plugin="org.eclipse.core.runtime"/>
   </requires>
   
   <extension
          point="org.eclipse.ui.actionSets">
       <actionSet
             label="Sample Set"
             visible="true"
             id="org.eclipse.sample.actionSet2">
          <menu
                label="Sub Menu"
                path="complexMenu/complexGroup"
                id="subMenu">
             <separator
                   name="complex2Group">
             </separator>
          </menu>
          <menu
                label="Sub Sub Menu"
                path="complexMenu/subMenu/complex2Group"
                id="subSubMenu">
             <separator
                   name="complex3Group">
             </separator>
           </menu>
          <action
                label="Sample Action More Complex"
                icon="icons/sample.gif"
                class="org.eclipse.sample.SampleAction"
                tooltip="Hello, World"
                menubarPath="complexMenu/subMenu/subSubMenu/complex3Group"
                id="org.eclipse.sample.SampleAction">
          </action>
       </actionSet>
   </extension>
   

</plugin>
Comment 1 Pat McCarthy CLA 2005-01-17 15:57:34 EST
Comment on the work-around after further discussion with people impacted by 
this bug.  

If we copy the menu definition from another plug-in, we may run the risk of 
breaking subsequent translation/reaction to NLS runtime choice changes if all 
the translated strings (with the expected values) are not found in the plug-in 
that copies the menu structure.  And if this workaround is used by multiple 
plug-ins who sort before the original plugin, that would only add to the 
confusion related to source definitions, translated values, and all that fun 
stuff.

This issue grows to impact many players when products start offering menu 
targets for use by others that also contribute plugins. 

We'd hate to have to tell them to pick a plugin id that sorts first, but it 
may happen to avoid the other complexities.

Maybe this is a bit above a P3 - but I'll let someone else make that call.
Comment 2 Douglas Pollock CLA 2005-01-18 14:47:54 EST
Priorities are usually used by the developer, and not by reporters.  You can 
up the severity if you feel this is a "major loss of function". 
 
But, that aside.  We know about this problem, and we are working toward a 
solution.  I'd invite you to pay attention to 
"http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/R3_1/dynamic_teams/dynamic_teams.html#actionContributions". 
 
 
Comment 3 John Arthorne CLA 2005-02-22 12:49:12 EST
Bug 36389 appears to be a duplicate of this, or at least strongly related.
Comment 4 Michal Tkacz CLA 2005-08-27 13:28:52 EDT
I think that this bug, bug 15670 and bug 36389 reference the same problem. If
so, please mark two of them as duplicates. 
Comment 5 Michael Van Meekeren CLA 2006-04-21 13:56:29 EDT
Moving Dougs bugs
Comment 6 Paul Webster CLA 2007-04-05 19:03:52 EDT
Assigning to component owner
PW
Comment 7 Paul Webster CLA 2007-06-21 10:37:03 EDT

*** This bug has been marked as a duplicate of bug 15670 ***