Previous Page
Next Page

20.6. Modifying Eclipse to Find Part Identifiers

Defining new actions using the plug-in manifest editor is a straightforward process, except for finding those pesky identifiers for extending the context menus of specific views and editors (see Section 6.4, View Actions, on page 237 and Section 6.5, Editor Actions, on page 244). This information is not part of any plug-in manifest and thus must be obtained in some other manner.

One approach is to start with the registerContextMenu method in the org.eclipse.ui.internal.PartSite class and search for references, exploring the code and recording identifiers as you go. This is a viable but time-consuming approach that tends to become out of date as new versions of Eclipse arrive.

An alternate approach is a development utility that interrogates the active workbench part, be it an editor or a view, and dumps information about that part, such as the context menu identifiers, to the console. Unfortunately, the API for obtaining this information does not exist (see Section 20.2, Accessing Internal Code, on page 711), so before creating an action delegate, you need to modify the underlying Eclipse system to provide the appropriate accessor methods.


You can download and install this part information utility from

20.6.1. Modifying the Eclipse base

To modify the Eclipse base, you first need to check out the appropriate project from the Eclipse repository so that later you can create and submit a CVS patch. Submitting a CVS patch is how such changes are fed back to the Eclipse committers with the hope of getting integrated into the development stream. Connect to the development repository by opening the CVS Repositories view (see Section 1.8.1, Getting started with CVS, on page 49) and selecting New > Repository Location. In the Add CVS Repository dialog, enter the following values.

Host ""

Repository Path "/home/eclipse"

User "anonymous"

Password Leave this blank.

Connection Type "pserver"

Once connected, expand the HEAD tree element, locate the org.eclipse.ui.workbench project, and check it out in the workspace (see Section 1.8.2, Checking out a project from CVS, on page 50). Once it is checked out in the workspace, there may be some compile errors in the Problems view because the Eclipse being used may be different from the Eclipse against which the plug-in project was compiled. The plug-in project is compiled against the HEAD versions of other plug-in projects, but since it cannot locate those other plug-in projects in your workspace, it compiles them against the plug-ins in the current Eclipse installation. The following are several different ways to remedy this situation.

  • Check out each Eclipse plug-in project on which this plug-in project directly or indirectly depends.

  • Download and install (but do not launch) the latest Eclipse integration build, then retarget your current Eclipse environment to compile against plug-ins in the integration build using the Plug-in Development > Target Platform preference page (see Section 19.2.5, Editing with different versions of Eclipse, on page 692). The disadvantage is that all other plug-in projects in your workspace will also be compiled against this target platform.

  • Check out a prior version of the plug-in project that compiles against the plug-ins contained in your Eclipse installation. The disadvantage is that if any of the code you write depends on functionality that has changed between the version you checked out and the HEAD, then it may not compile when you submit it back to

  • Do as much as you can using one of the preceding approaches, then wait until the next Eclipse milestone build is released (they are usually very stable, whereas various integration builds are not). Download, install, and code against the new build and submit your changes as soon as possible back to

When the org.eclipse.ui.workbench project is loaded and its compile errors cleaned up, add the following methods.


public String getMenuId() {
   return menuID;


public String[] getContextMenuIds() {
   if (menuExtenders == null)
      return new String[0];
   String[] menuIds = new String[menuExtenders.size()];
   int index = 0;
   Iterator iter = menuExtenders.iterator();
   PopupMenuExtender extender;
   while (iter.hasNext()) {
      extender = (PopupMenuExtender);
      menuIds[index] = extender.getMenuId();
   return menuIds;

20.6.2. Creating the global action

Next, you will create an action delegate capable of using this newly introduced API. In the plug-in project of your choice (e.g., the Favorites plug-in project, but not the org.eclipse.ui.workbench plug-in project), define a new workbench menu and menu item in the plug-in manifest (see Section 6.2, Workbench Window Actions, on page 209), give it a name similar to "Show Part Info," and associate it with the action delegate that follows. Be sure to modify that plug-in's classpath to reference the org.eclipse.ui.workbench project in the workspace rather than the org.eclipse.ui.workbench external plug-in, and make sure that org.eclipse.ui.workbench is in the required plug-ins list in the plug-in manifest.

package com.qualityeclipse.favorites.actions;

import ...

public class ShowPartInfoActionDelegate
   implements IWorkbenchWindowActionDelegate
   public void init(IWorkbenchWindow window) {
      // ignored

   public void selectionChanged(IAction action, ISelection selection)
      // Ignored.
   public void run(IAction action) {

      // Determine the active part.
      IWorkbenchPage activePage =

      IWorkbenchPart activePart =

      // Search editor references.
      IEditorReference[] editorRefs =

      for (int i = 0; i < editorRefs.length; i++) {
         IEditorReference eachRef = editorRefs[i];
         if (eachRef.getEditor(false) == activePart) {
               (IEditorPart) activePart);

      // Search view references.
      IViewReference[] viewRefs =

      for (int i = 0; i < viewRefs.length; i++) {
         IViewReference eachRef = viewRefs[i];
         if (eachRef.getView(false) == activePart) {
            printViewInfo(eachRef, (IViewPart) activePart);

   private void printEditorInfo(
      IEditorReference editorRef,
      IEditorPart editor) {

      printPartInfo(editorRef, editor);

   private void printViewInfo(
      IViewReference viewRef,
      IViewPart view) {

      printPartInfo(viewRef, view);
   private void printPartInfo(
      IWorkbenchPartReference partRef,
      IWorkbenchPart part) {

      println("  id = " + partRef.getId());
      IWorkbenchPartSite site = part.getSite();
      if (site instanceof PartSite) {
         String[] menuIds =
            ((PartSite) site).getContextMenuIds();
         if (menuIds != null) {
            for (int i = 0; i < menuIds.length; i++)
               println("  menuId = " + menuIds[i]);

   public void println(String line) {

   public void dispose() {
      // Ignored.

20.6.3. Testing the new utility

Create a new launch configuration (see Section 2.6, Debugging the Product, on page 88) and launch a Runtime Workbench to test the new utility. Be sure to modify the launch configuration so that it references the org.eclipse.ui.workbench project in the workspace rather than the org.eclipse.ui.workbench external plug-in. When you activate an editor or view and then select the new global action from the workbench menu bar, you will see the workbench part's information appear in the Console view of the Development Workbench.

20.6.4. Submitting the change to Eclipse

After you've created a useful addition to Eclipse and decided that it's of no real commercial value yet it might really help other developers, you can post it to a Web site for others to download and use as they choose; or better still, you can submit it to for inclusion in the Eclipse base via Bugzilla (see Section 20.2.2, BugzillaEclipse-bug tracking system, on page 712).

For example, if you were to submit the modifications made to the Eclipse base (see Section 20.6.1, Modifying the Eclipse base, on page 727), you would follow these steps:

  1. Open a Web browser to the Eclipse Bugzilla page ( and search the submissions to see whether someone has already had the same thoughts you have had and already posted a bug or feature request (e.g., we've already posted this code to Bug # 39782).

  2. If, after a search you've determined that your contribution has not been made by anyone else, then package up your modifications to the Eclipse base code in a CVS patch. To create a patch for submission to, select the Eclipse project containing your modifications, right-click, and then select Team > Create Patch... . Note that the patch creation functionality can only be used on a project checked out from a repository, such as (see Section 20.6.1, Modifying the Eclipse base, on page 727)r not from imported binary or source plug-in projects.

  3. Either create a new bug report and append your patch or append your patch to an existing bug report. Be sure to explain what the patch contains and why you think it should be included in the Eclipse base code.

Previous Page
Next Page