Community
Participate
Working Groups
Build Identifier: I20100608-0911 Xtext Unwanted Menu contributions in RCP: Eclipse Helios Version: 3.6.0 Build id: I20100608-0911, Xtext 1.0.0 When including new Xtext plug-ins as a dependency to a RCP application in eclipse Helios, Xtext contributes two unwanted menu items on the Main menu (MenuManager): 1) Search menu 2) A menu with no label and no visible menu items - Under the debugger it was evident that this appears to be a run menu with debug commands StepIn, StepOver...etc The problem can be demonstrated by creating an example RCP plug-in project via the wizard dialog, creating a new Xtext project via Xtext wizard and including the Xtext plugins as a dependencies to the RCP application. It would appear that one of the Xtext dependencies is contributing these MenuItems. Is there a workaround for this? Or is it a bug? Reproducible: Always Steps to Reproduce: 1.create an example RCP plug-in project via the wizard dialog 2.create a new Xtext project via Xtext wizard 3.include xtext generated plugins as dependencies to RCP plug-in. 4.launch RCP generated app. 5.unwanted menu items are visible.
The problem exists in non-rcp contexts as well. E.g. a right click in the mwe2 outline reveals a bunch of menu entries that are more or less pointless and distracting in this context.
As menus and menu items are contributed declaratively by means of extension points, you should restrict the plug-ins of your RCP to the minimum of dependencies. For your run configuration, you can do this in the plug-ins tab (Run->Run configurations...->Plug-ins). Choose "Launch with" plug-ins selected below, deselect all and add only the required ones. This will make the empty menu go away. I don't know where it am from, but it shouldn't matter for us. Note that you can also skip optional dependencies by checking the box below the tree. If you just depend on the runtime plug-in of your language, this will also make the "Search" menu disappear. If you need the .ui plug-in of your language, e.g. because you want the editor, you will get the "Search" menu, as this is provided by org.eclipse.search, which is a direct dependency of org.eclipse.xtext.ui. We rely on classes from org.eclipse.search for the "Find references" infrastructure. That's why I'd rather not make this dependency to org.eclipse.search optional, as it would be hard to find for other users who want "Find references" and have to put it into their RCP. Into the bargain, there will be a lot of second/third/... level dependencies on the evil plug-in which we cannot eliminate easily. The easiest workaround for you is to disable the contributions from org.eclipse.search by means of an activity. Simply add <extension point="org.eclipse.ui.activities"> <activity description="My RCP Activity" id="my.rcp.activity" name="MyRCP"> </activity> <activityPatternBinding activityId="my.rcp.activity" pattern="org\.eclipse\.search/.*"> </activityPatternBinding> </extension> As no capabilities are set by default, all contributions from org.eclipse.search will be omitted.
(In reply to comment #1) > The problem exists in non-rcp contexts as well. E.g. a right click in the mwe2 > outline reveals a bunch of menu entries that are more or less pointless and > distracting in this context. Most contributions were due to the fact that we addapted everthing to IFile. Lots of plug-ins contribute context menu actions adaptively to IFile. Two submenus "Run as" and "Debug as" remain.
Most context menu contributions were given by o.e.xtext.xtext.ui: We added AdapterFactories for IContentOutlineNodes in general in the plugin.xml. I removed these including the adapter factory for ILaunchable, which resulted in the "Run As" and "Debug as" submenus. The backside is that client can no longer call "Generate Xtext Artifacts" from the outline of an Xtext grammar editor. I guess we can live with that. Another problem is that we register the language specific IContentOutlineAdapterFactory globally for IContentOutlineNodes in the XtextOutlinePage. This will pollute the outline of other languages, as it is never deregistered. We will have to refactor this as soon as API changes are allowed again, so I marked the involved classes / interfaces as deprecated. Clients who want to add context menu actions to their outlines should rather implement their own IContentOutlineNode with their language specific getAdapter(Class x) method.
Do we have to update the documentation?
Closing bug which were set to RESOLVED before Eclipse Neon.0.
