Jeff Mesnil

Hook when hovering on a menu item in Eclipse

I’m trying to display a message in Eclipse global status bar when hovering on a menu item.

I had the part to display the message (but I’m pretty sure it’s the ugliest way I could have found):

    if (window instanceof ApplicationWindow) {
        ApplicationWindow appWindow = (ApplicationWindow)window;
        appWindow.setStatus(message);
    }

But I can’t find how to run that code when hovering on a menu item. I’ve got the complete control on the menu and its items creation but I don’t see where I can plug my code so that it is executed when hovering on a item of my menu.

The reason I need that code is that I’d like to display a description of a Eclipse Monkey script when hovering on a menu item in the Monkey menu (see bug #132601 for a description of this enhancement).

If anyone has an idea, I’d appreciate.

“Find Missing Headers” Monkey Script

Still playing with Eclipse Monkey.

I wrote this simple script based on the org.eclipse.dash.doms resources DOM. It looks for Java files to find the files which are missing copyright headers. In my script it is looking for the Eclipse Foundation copyright (Copyright (c) 2005 Eclipse Foundation).

 --- Came wiffling through the eclipsey wood ---
   /*
    * Menu: Find Missing Headers
    * Kudos: Jeff Mesnil
    *  License: EPL 1.0
    * DOM: http://download.eclipse.org/technology/dash/update/org.eclipse.dash.doms
    */

   function main() {
     var files = resources.filesMatching(".*\\.java");
     var match;
     for each( file in files ) { 
       file.removeMyTasks(  );
       if (!file.lines[1].string.match(/\* Copyright \(c\) 2005 Eclipse Foundation/)) {
            file.lines[1].addMyTask(file);
       }
     }
       window.getActivePage().showView("org.eclipse.ui.views.TaskList");
   }

   --- And burbled as it ran! ---

If I run it on my workspace with the imported org.eclipse.eclipsemonkey plug-in, it shows that one file is missing the copyright header:

workspace and window variables in Eclipse Monkey

I’m playing with Eclipse Monkey and its DOM examples.

At first I did not understood in the Find_System_Prints.em example where the window variable was coming from.
After diving into in the org.eclipse.eclipsemonkey plug-in source code, I found out that it is defined as a standard global variable in RunMonkeyScript.defineStandardGlobalVariables(Scriptable scope) method.
Incidentally, it is the only global variable added by Eclipse Monkey.

The following code is also commented in this method (in version 0.1.6 of the o.e.eclipsemonkey plug-in):

// Object wrappedWorkspace = Context.javaToJS(ResourcesPlugin
// .getWorkspace(), scope);
// ScriptableObject.putProperty(scope, "workspace", wrappedWorkspace);

The workspace variable is instead contributed by the org.eclipse.dash.doms plug-in.

To sum up, window is available for free in your Monkey scripts while you will have to reference the http://download.eclipse.org/technology/dash/update/org.eclipse.dash.doms DOM to have access to the workspace variable.

EclipseCon’06 is approaching

EclipseCon’06 is approaching and I haven’t yet chosen the talks I want to attend. There are so many things related to Eclipse which interest me:

• OSGi/Equinox
• RCP
• TPTP
• Eclipse Monkey

It’ll be hard to choose between so many talks but I’m eagerly waiting to learn more about Eclipse Monkey. Ward Cunningham and Bjorn Freeman-Benson envisioned it as just a team tool but Wayne Beaton is already pushing it and uses it to script a RCP application.

Anyway, see you at EclipseCon’06! And if you’re interested by RCP and TPTP technology, I’ve a short talk about integrating TPTP in a RCP application which might interest you.

Eclipse Monkey has been released

From its Web page:

Eclipse Monkey is a dynamic scripting tool for the automation of routine programming tasks. Monkey scripts are little Javascript programs using either the Eclipse APIs or custom Monkey DOMs.

I downloaded it and installed it on Eclipse 3.1.1 and it is promising.
It seems inspired a lot by greasemonkey and I’d like to see what kind of scripts the Eclipse community will create.

A first script I’d really like to get is to transform code comments like //BUG 12345 into a clickable URL to our bug tracker.

A concrete example of what can be done with Eclipse Monkey is Wayne Beaton’s Flickr script

Kudos to Ward Cunningham & Bjorn Freeman-Benson

Logging templates for eclipse

Following Wayne Beaton‘s post on more templates with eclipse, here is an example of template that I extensively use in eclipse to ease logging statements. For each logging level (debug, info, warn, error, fatal), I defined a corresponding templates. For example, I have a debug template:

if (logger.isDebugEnabled()) {
   logger.debug(${cursor});
}

It makes it simpler and quicker to write logging statements. However the class won’t compile if a logger field has not already been defined. But in that case, either you can use eclipse’s quick fix… or create a new template to define the logger.

Developer talk at EclipseCon’06

My talk about Integrating TPTP in a RCP Management/Monitoring Console has been accepted for EclipseCon’06.

See you there!

Label Decorations in Eclipse

During the development of an Eclipse plug-in, I wanted to add label decorations to a view. The article Understanding Decorators in Eclipse is a good reference but I couldn’t make it work in my own plug-in. This article is omitting a key information: The label provider you want to decorate needs to accept decorations, it must be wrapped in a DecoratingLabelProvider. For now, I haven’t found a way to find that information declaratively. So if you want to decorate a label provider provided by another plug-in, you have to browse its code to find out if it can be decorated or not.

As an example, to make my own ILabelProvider decorable, I had to change the code in my view from:

viewer.setLabelProvider(new MyLabelProvider());

to:

viewer.setLabelProvider(
  new DecoratingLabelProvider(
    new MyLabelProvider(),

    PlatformUI.getWorkbench().getDecoratorManager().getLabelDecorator()));

With that change, I could contribute declaratively a lightweight decorator extension (i.e. in another plug-in) to this provider without any trouble.

Testing an Eclipse plug-in in isolation

All this post just to ask a simple question: how to test an Eclipse plug-in in isolation?

I’m currently writing an Eclipse feature to manage a server through JMX. It is composed of 3 plug-ins:

• the JMX plug-in is used to create on demand the MBean proxies and handle all the low-level JMX stuff (connections, authentication, etc.)
• the Core plug-in is my domain model. it provides core objects which, in addition of the management methods of the MBeans, provide navigation methods to easily move between them (the core objects are in a way proxies of the MBean proxies…)
• the UI plug-in uses the core objects provided by the Core plug-in for display and user interaction.

As an aside, I don’t use the MBeans directly as my domain model. To have an object-oriented domain model has two advantages:

1. the navigation between the objects is simple to use and self-described by the API
2. I can integrate better with Eclipse since my core objects implements IAdaptable (adapters are implemented in the UI plug-in)

So I’d like to test the Core plug-in in isolation to ensure the consistency of my domain model based on the MBeans. However I don’t want to use the “real” MBeans because most of the code I want to test is destructive and will alter the state of the managed objects on the server side making it too much difficult to run tests in isolation.

My first idea was to mock the JMX plug-in so that it returns mocked MBeans that I can use to unit test the Core plugin.
It sounds quite simple but I haven’t yet find a way to make it work…

The first dirty hack that I tried was to create a JMX Mock plug-in with the same ID and API than the real JMX plug-in and use that one in the test launch configuration but Eclipse is (understandingly!) not happy about having two plug-ins with the same ID. Anyway, it is ugly because the JMX Mock plug-in wouldn’t have any relation with the real JMX plug-in but a copy-paste…

Another dirty solution would be that the JMX plug-in itself could either return the real MBeans or the mocked ones. But is is so ugly and wrong that I really don’t want to go that way…

I searched on Google and Eclipse mailing lists about ways to test Eclipse plug-ins in isolation but I didn’t found any good advices.
In fact I haven’t found information about mocked plug-in (but thousands and thousands of plug-ins generating mocks, sigh…).

All that said, I just have two simple questions:

• how to test a plug-in in isolation?
• how to provide a mocked plug-in which is injected in another plugin at runtime?

Disclaimer: I’m relatively new at plug-ins development and I really wonder if I’m not missing something obvious for experienced plug-ins developers…)