March 19, 2006
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 this DOM URL to have access to the workspace variable.
March 14, 2006
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:
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.
March 3, 2006
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
March 1, 2006
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:
{% highlight java%} if (logger.isDebugEnabled()) { logger.debug(${cursor}); } {% endhighlight %}
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.
February 14, 2006
After Innobase, Oracle has bought Sleepycat, the maker of the great database engine BerkeleyDB. Congratulations to the Sleepycat team!
As an aside, Oracle now owns the developers of InnoDB and BDB, two of the most popular transactional table formats used by MySQL database.
Shouldn't MySQL AB start to worry about that?
February 14, 2006
Eamonn McManus's Blog: What is an MXBean?
One of the important new features of the JMX API in Mustang (Java SE 6) is the ability to create MXBeans. MXBeans provide a convenient way to bundle related values together without requiring clients to be specially configured to handle the bundles. Here's the complete story about MXBeans.
Great new feature for JMX-based applications. When I read articles like that, I wish I could already use Java SE 6 in our production code because it could tremendously reduce the burden of JMX handling.
February 8, 2006
My talk about Integrating TPTP in a RCP Management/Monitoring Console has been accepted for EclipseCon'06.
See you there!
January 19, 2006
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.
August 30, 2005
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:
- the navigation between the objects is simple to use and self-described by the API
- 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...)
June 7, 2005
So now that the news is official that Apple will move its laptops to Intel X86 architecture, I'm wondering what it means for Java. I'm neither a hardware guy nor an OS one but if the architecture is based on X86 and the OS on an UNIX kernel, what are the implications for Java? Will it be simpler for Apple to develop their own JVM? Can they leverage Open Source projects (no, I'm not talking about Harmony!)?
My hope is that there will be less lag between Sun JVMs on Wintel and Linux and Apple one. However, since Apple seems committed to support both PowerPC and X86 architectures, will they accept to have two different versions of Java (the X86 one following closely Sun ones and the PowerPC one still lagging a few months behind)? Or will they keep only one version and, unfortunately but realistically, the older one? Java was much heralded by Steve Jobs when Apple released Mac OS X but it has never really become a first-class citizen for application development. Now with the move to Intel and the continuing support for PowerPC, it may renew the interest of developers.
That and the availability of SWT for Cocoa would mean a new age for Java application development on Apple boxes...