Eclipse Common Navigator Framework in RCP Applications

Eclipse is- amongst being an IDE and almost everything else- a powerful development environment for cross-platform rich client applications (RCP).

One particular feature of the Eclipse IDE is the framework for working with resource, more specifically the workspace resources. Michael Elder documented the Common Navigator Framework (CNF) in a series of articles in his blog.

Unfortunately, at the time of writing, CNF does not easily lend itself to use in RCP applications. A number of usenet postings and Eclipse bugs describes this problem. While a number of things still needs to be done to externalize the CNF API from the Eclipse IDE to allow clean use in RCP apps, a working solution exists today.

The following solution is derived from the sources mentioned above, full credit given:

  1. ApplicationWorkbenchAdvisor

    public void initialize(IWorkbenchConfigurer configurer) {

    public IAdaptable getDefaultPageInput() {
    return new NavigatorRoot();

    public void preStartup() {

    The code for declareWorkbenchImages() including declareWorkbenchImage() is copied from org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.

  2. New NavigatorRoot class.

    The new NavigatorRoot implements IPersistableElement. This ensures that the class can be persisted when saving the workbench state. Otherwise, the navigator root element is not read when restoring the workbench state.

    public class NavigatorRoot implements IAdaptable, IPersistableElement, IElementFactory {
    public NavigatorRoot() {

    public Object getAdapter(Class adapter) {
    if (adapter == IPersistableElement.class)
    return this;
    if (adapter == IWorkbenchAdapter.class)
    return ResourcesPlugin.getWorkspace().getRoot().getAdapter(adapter);
    return null;

    public String getFactoryId() {
    return this.getClass().getCanonicalName();

    public void saveState(IMemento memento) {
    // TODO Auto-generated method stub

    public IAdaptable createElement(IMemento memento) {
    return ResourcesPlugin.getWorkspace().getRoot();

  3. ElementsFactory Extension.

    To be sure the NavigatorRoot class can be instantiated when reading the workbench state, it’s createElement() method must be available. This is achieved in the previous chapter by implementing IElementFactory and now registering it in the elementsFactory extension in plugin.xml:
    extension point="org.eclipse.ui.elementFactories"
    factory class="rcpCNF.NavigatorRoot" id="rcpCNF.NavigatorRoot"

    At this point the navigator is already fully functional- but does not yet show any data/projects or actions to act on the data.

  4. Configure the Navigator

    To use the new navigator, the navigator must be configured and content needs to be added. This is done by using the org.eclipse.ui.navigator.viewer extension.
    Using this extension, we declare:

    1. Which viewer we’d like to configure (viewer).
    2. Which content we’d like the viewer to display (viewerContentBinding).
    3. And which actions to expose to the user (viewerActionBinding).

A working example with full source code is available here in this RCP Navigator Example (updated).

15 Responses to “Eclipse Common Navigator Framework in RCP Applications”

  1. Jef Gearhart Says:

    Hi Andreas,

    You are awesome. I’ve been working with your example. In my environment, if I start with a scratch workspace, then create a “General Project” using the wizard, the project gets created on disk, but the Navigator never shows it. I can create many projects, refresh, refresh.. and I see nothing. Restarting does show it, and everything works as expected from there.

    Eclipse 3.2.1
    Java 5

    Have you seen this before?

    Many thanks!

  2. Jef Gearhart Says:

    Duh, I now see from the original pos that you HAVE seen this before. But it l seems that your sample still behaves this way out of the box. Any ideas?

    BTW, I’m debugging and I see different behavior during start up in the two scenarios (scratch wkspc vs. existing wkspc).

    The diffs are..

    scratch – getDefaultPageInput() is called, createElement() is not
    existing – createElement() is called, getDefaultPageInput() is not


    confused but not defeated.

  3. Jef Gearhart Says:


    deleted NavigatorRoot class…
    deleted elementFactory previously added to plugin.xml
    replaced getDefaultPageInput in hack to

    IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
    return root;

    Voila! Everything seems to work perfectly. Scratch, scratch..

    Still seem to need the AdvisorHack though.

    Baffled… but happy!:)

    (all jokes aside, maybe I’ll dig further into this in the future, but for now, I’m assuming I missed someone’s advice somewhere, and moving on).

    Version: 3.2.1
    Build id: M20060921-0945

  4. John Emerson Says:

    I understand that this has been reported before, however I wonder if the problem has cropped up again under 322.

    I have tried with Eclipse 322 on both Windows (JRE 1.5.0_11) & MacOS (JRE 1.5.0_06). In both cases I saw the same behavior reported by Jef Gearhart. New projects don’t show up unless their parent directory exists at runtime, for example, runtime-rcpCNF.product. The same is true when a product is exported via the product export wizard.

    I would appreciate any help in this regard. Thanks in advance,
    John Emerson

  5. John Emerson Says:

    Jef’s solution works with eclipse33M5eh. I’m curious to know when this workaround will be incorporated into 3.3. I incorrectly assumed it already had been in 33M5eh.

  6. Using the Common Navigator Framework in an RCP Application « RCP Quickstart Says:

    […] developers have gone through a lot of pain trying to get the CNF to work, and most of these attempts involve trying to fake out the mechanism […]

  7. zakir Says:

    Hi This problem of no images nor project name in the navigator explorer..

    it can be resolved by capturing the total code from the into your advisor class of your own RCP and then run the application.

    I tried now my previous problem what i was getting of no name nor icon is resolved…

    Thank god………………….

    I struggled a lot

  8. Kevin McGuire Says:

    In 3.3 I20070524 on Vista, I took the example attached and was able to get it to work by replacing getDefaultPageInput with

    IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
    return root;

    as Jef suggested in his comment January 17th, 2007, but with no other changes suggested.

    Note that the following line from the example in WorkbenchAdvisorHack.declareWorkbenchImages() now results in a compile error:

    declareWorkbenchImage(ideBundle, IDEInternalWorkbenchImages.IMG_LCL_LINKTO_HELP,

    because that key IMG_LCL_LINKTO_HELP no longer exists.

  9. Greg Says:

    Hi Andreas,

    I don’t know if you can point me in the right direction?

    I’m stuck! My RCP Project uses the CNF heavily to display Workspace resources, but I need to remove the Copy, Paste, Delete, Move and Rename actions from the pop-up menu. I’ve been looking for some time, but have found no solution, just similar unanswered questions. Any suggestions would be greatly appreciated!

  10. Greg Says:

    Thanks for the reply. I tried setting allowPlatformContributions to false, but the group.edit and group.reorganise groups still seem to be being populated! I didn’t expect that!

    I’m unsure how to stop it, because I need to prevent or override delete / copy / paste types of actions. I’ve tried not adding the insertionPoint for group.edit and group.reorganize – which works, but it writes out “group not found” exceptions to the log. From a support perspective, that isn’t acceptable.

    Any suggestions, this is starting to become a major issue for the project…

  11. Greg Says:

    Hi andig,

    Thanks for getting back to me. I’ve read the links you mentioned but I’m still stuck. It’s been suggested that I define a viewer with a blank popup like this:

    I agree that this should work, but I still get the copy, paste, delete, move and rename actions (from the “group.edit” and “group.reorganize” groups). If I define my own viewer popup insertionPoints and leave out those two groups, I get java.lang.IllegalArgumentExceptions: Group not found exceptions written to my log.

    I am baffled as to why those two groups insist on being there. I am desperate for a solution because this issue has now become critical blocker to my project.

    Many thanks


  12. Greg Says:

    …and here is my plugin.xml section for the cnf:

    My CustomCommonNavigator does work fine – it just extends the CommonNavigator Class and overrides the single getInitialInput method with the following code:

    protected IAdaptable getInitialInput() {
    return ResourcesPlugin.getWorkspace().getRoot();

  13. Greg Says:

    …my plugin.xml didn’t come through for some reason. I’ll try again, this time I’ve replaced the greater and less-than characters with square brackets. Sorry for littering you’re page:

    [extension point=”org.eclipse.ui.navigator.viewer”]
    [viewer popupMenuId=”mynavigatorpopup” viewerId=”mynavigator”]
    [popupMenu allowsPlatformContributions=”false” id=”mynavigatorpopup”]
    [insertionPoint name=”mygroup”/]
    [viewerContentBinding viewerId=”mynavigator”]
    [contentExtension pattern=”org.eclipse.ui.navigator.resourceContent”/]
    [contentExtension pattern=”org.eclipse.ui.navigator.resources.filters.*”/]
    [extension point=”org.eclipse.ui.navigator.navigatorContent”]
    [navigatorContent id=”mynavigator”
    [extension point=”org.eclipse.ui.views”]
    [view id=”mynavigator” class=”mypackage.CustomCommonNavigator” name=”Navigator”/]

  14. Duncan Krebs Says:

    Dude.. Thank you so much, this framework sucks for using alone in RCP, I was finally able to the images to be displayed after looking at what you did in your example WorkbenchAdvisorHack .. much appreciated. this was a good
    wasted 4 hours

  15. » Blog Archive » Using the Eclipse Common Navigator Framework in RCP Says:

    […] […]

Leave a Reply