Archive for August, 2008

How to brand Eclipse RCP?

August 7th, 2008  |  Published in Uncategorized

In response to my last post on Eclipse RCP Trends, Chris Aniszczyk commented:

Deep down inside… I think it’s a marketing issue… we have done a poor job marketing RCP in my opinion. We have brand confusion that when people hear Eclipse still they think IDE, not a rich client platform. It’s my hope that with the new Runtime project, we have a chance to rebrand Eclipse into more of a platform under the Equinox umbrella.

I couldn’t agree more, and I’ve spent some time this summer trying to wrap my head around this issue. I should say up front that I have zero marketing experience. But on the other hand, I have spent a lot of time with RCP newcomers and have some experience viewing this technology through their eyes.

So what did I come up with? Well this might sound pretty obvious to some, but my conclusion is that RCP = modularity. Period. If you want to assemble (dynamically or otherwise) an application from a set of components/plug-ins/bundles/whatever, then RCP is the tool for you. Sure it’s a UI toolkit, sure it offers a workbench, preference pages, etc. But the core idea that animates RCP is modularity.

The good news is that Java modularity in general and OSGi/Equinox in particular are playing an increasingly important role in software development. We need to ride this trend and make clear that RCP is the visual expression of Java modularity. When you want to apply the principles of Java modularity in the UI space, RCP is the tool for you.

From a marketing point of view, this brings me to the same conclusion that Chris reached above. Basically, RCP needs to be rebranded as part of a suite of technologies related to Java modularity. In other words, RCP needs to become the Equinox UI.

Eclipse RCP Trends

August 7th, 2008  |  Published in Rich Client Platform

I’ve been having some fun today with Google Insights for Search, and of course my first thought was to examine trends relating to the Eclipse Rich Client Platform. And what did I find? Here is a chart showing historical data beginning in 2004 for the search “eclipse rcp”.

First, this is just awesome data! You can drill down to individual countries, states/provinces or even cities. I could play with this all day, but I really should get back to work!


Unfortunately the news isn’t good for Eclipse RCP. It’s interesting that while Eclipse RCP job postings are trending up, the search statistics are telling a different story. The stats for RCP look even worse when you compare them to Adobe Flex, which many (mistakenly, I believe) think of as a substitute for RCP.

We obviously need to do a much better job promoting Eclipse RCP. There are so many things involved with this, including making the platform easier to use (hopefully the e4 project will help) and also communicating clearly what Eclipse RCP is and why it’s useful. I’ll have something to say about this later point in upcoming posts, but I’d be curious to hear what others have to say. What do you think can be done to better promote Eclipse RCP?

Updated PDE Build and Test Example

August 4th, 2008  |  Published in Builds, Rich Client Platform, Testing, Tips

I’ve just spent some time updating my example showing how to set up PDE Build and the Eclipse Testing Framework. I’ve generally cleaned things up and I’m now creating the test environment in the correct way.

As a special bonus, I’ve also thrown in coverage analysis using EMMA. And before people ask, yes I have tried to use Clover with PDE Build, but have had little luck due to Clover’s dependence on a specialized Java complier. If anyone has gotten this to work, I’d love to hear about it.

And finally, I had to change this example to use a test plug-in instead of a test fragment. For some reason when running Eclipse 3.4 (maybe related to p2?), the ETF is not finding tests in fragments. If anyone has any ideas here as well, please let me know.

You can download the new example here.

NOTE: I’ve discovered that the EMMA instrumentation task fails if you’re running the script inside of Eclipse and you have spaces in your workspace path. Avoid spaces in your path and you should be good to go.

Update – October 6, 2009: The sample projects have now been updated to work with Eclipse 3.5.1

Creating a test environment for the Eclipse Testing Framework

August 1st, 2008  |  Published in Uncategorized

Running unit tests with the Eclipse Testing Framework can be a real pain. I’ve tried to provide some help in previous posts. But one thing I haven’t addressed is how to properly set up a unit test environment.

The first question you might have is what is a test environment and why do I need one?. Well the short answer is that the Eclipse Testing Framework has a set of plug-ins it needs to run. The complete set of necessary plug-ins I refer to as a test environment. Yes, I just made this up, but it works for me.

In almost all cases, a test environment is composed of three things:

  1. A complete copy of the Eclipse SDK.
  2. The Eclipse Testing Framework.
  3. Your code. This includes both your production plug-ins along with any plug-ins or fragments containing unit tests.
I prefer to create this test environment on the fly during the build process. This is much cleaner than polluting a version of Eclipse that you use for development or even the instance that you use to run PDE Build. So my first tip:


Always create a test environment from scratch every time you run your unit tests. Create a new directory, add the Eclipse SDK, the ETF, and finally your own compiled plug-ins.


It’s also important to create the test environment in the correct way. The biggest mistake people make is to attempt to copy the Eclipse installation that exists on their machine. The main reason this is a problem is that you can’t be running that instance of Eclipse during the copy operation. If you do, you will probably get errors indicating that files are locked and cannot be copied to the test environment. Another problem is that a previously run instance of Eclipse will have a ton of metadata and config info associated with it. Copying all of this will seriously slow down your build and can potentially complicate the running of JUnits. So my second tip is:


Always start the creation of your test environment by extracting an archived Eclipse SDK of the appropriate version.


Hopefully these tips will help make it somewhat easier to use the Eclipse Testing Framework. It’s really not so bad, once you get things set up properly.