Modular Mind

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

Eclipse provides great tools for testing RCP and OSGi applications using JUnit, but there a few areas that are problematic.

• It’s not easy to run all the tests in a set of plug-ins. The test launcher allows you to run all the tests in a single project, but RCP and OSGi developers are usually working with a large set of test plug-ins. Sure it’s possible to create test suites, but keeping suites up-to-date is a real pain.
• It’s not easy to use test fragments. To find out why you’d want to use test fragments instead of test plug-ins, check out my previous post on Testing Plug-ins with Fragments. The problem is that even the standard suite-based solution does not work with fragments. There are workarounds, but they’re not very pretty.
• It’s not easy to run all of your tests during an automated build using the Eclipse Testing Framework. This is related to the first point above, and again you can use suites to handle this. 

You can then run the test suite both inside of the Eclipse IDE and using the Eclipse Testing Framework. I should note that this works only for JUnit 3.x tests. JUnit 4 describes suites using annotations which makes it (as far as I can tell) impossible to dynamically generate a suite at runtime. If anyone has a solution to this, I’d love to hear it. 

As always, comments and fixes are much appreciated.

Setting up a target platform for an Eclipse Rich Client Platform application is fairly simple. You simply download the RCP SDK, extract it to a directory, and then use the Target platform preferences page to point to the new directory. But managing target platforms over time can be more complicated, and I’d like to pass along a few tips I’ve learned the hard way.

Maintain a separate target platform for each application.

The plug-ins that make up a target platform are as much a part of your application as the code you write, and this set of plug-ins will vary from one application to the next. One application might require the forms API. Another might use cheat sheets. Creating individual target platforms for each applications allows you to more easily manage these dependencies.

Make it easy for developers to create or link to target platforms.

Developers come and go on most projects and the first thing a new developer will need to do is set up a target platform. One way of making this easier is to create a wiki page listing the plug-ins that make up a target platform. Even better, just keep your target platform on a shared drive so everyone on the team can access it.

Version your target platforms.

Wiki pages and shared folders are great, but if you want to go all the way, consider versioning your target platforms along with your application source code. This makes it even easier to support new developers, and also makes it much easier to rebuild previous versions of your application.

Adding a new plug-in to your target platform is a big deal.

Adding a plug-in should be an explicit decision driven by your application’s requirements. When using the default target platform (Eclipse itself), it’s much too easy for developers to simply add dependencies on whatever plug-ins they like. Adding a new plug-in will generally require changes to your feature definitions, launch configurations, production configurations and automated build processes. Make sure the decision to add a plug-in to your application gets the deliberation it deserves.

A little work up front goes a long way.

Having said all that, I don’t want to make dealing with target platforms sound like rocket science. It’s usually a fairly simple aspect of RCP application development, as long as you treat it with the respect it deserves. The teams I see suffering from complications are those that never specifically address the issues posed by target platforms. With a little effort up front you can save yourself from some serious headaches.

One of the most important tips I have for beginning RCP developers is to please, please, please set up a custom target platform for your applications. As a trainer, it’s one of the first things I have students do. This is because target platforms are central to many other things we do as RCP developers, including the management of launch and product configurations. 

A target platform is simply the set of base plug-ins on which your application depends. By default, this target is set to be the entire collection of plug-ins shipped with Eclipse itself. So the first reason to set up a custom target platform is that the default is just messy. Why have hundreds of plug-ins in your target platform when you only need 20 or 30?

So setting up a target platform satisfies my sometimes excessive need for cleanliness, but there are other reasons as well. The best reason is that it decouples your application from the Eclipse development environment. Consider the following scenarios:

• You’d like to upgrade your Eclipse development environment to a milestone release, but you don’t want your RCP application to depend on beta plug-ins.
• You want to add GEF, EMF, BIRT or whatever to your application, but you don’t want to add it to your development environment.

In both cases, you’re out of luck if you’ve left your target platform defaulted to your Eclipse install. So save yourself some future headaches and set up a custom target platform.

I tried to think of a snazzier title for this post, but I’m in a literal mood I guess. So have you ever faced this problem? You want to use the FormEditor class (or it’s new subclass SharedHeaderFormEditor), but you only have a single page.

Sure, you can use FormEditor with a single page, but you’ll wind up with a single tab at the bottom of the editor. It looks a bit goofy:

Well the solution is surprisingly simple. In your subclass of FormEditor, just override the createPages method like this:

protected void createPages() {
	super.createPages();
        if (getPageCount() == 1 &&
		getContainer() instanceof CTabFolder) {
            ((CTabFolder) getContainer()).setTabHeight(0);
        }
}

This code hides the tabs when there is only one page, and you wind up with this:

Note that you need to call the super method before resizing the tab height, or this won’t work.

In this article I’m going to take you on a tour of the process I use to build a large-scale RCP application. Obfuscating an RCP application can seem like a big challenge, but it’s really not so bad.

Read the rest of this entry »

As Eclipse plug-in and Rich Client Platform developers, we face unique challenges in how we structure and execute our unit tests. In this article, I suggest an approach to unit testing based on Eclipse fragments that can help us overcome these challenges. If you find yourself frustrated with your current plug-in testing options, read on!

Read the rest of this entry »

One suggestion I always make to developers getting started with the Rich Client Platform is to set up a research workspace containing all of the Eclipse IDE plug-ins. The Eclipse IDE (along with the PDE and JDT) is the ultimate RCP application and examining this code is the best way to learn how things should be done.

Are you developing a forms-based editor? Check out the PDE UI plug-ins to see how the Manifest Editor is constructed. Would you like to create a preference page with an unusual UI layout? Look through the many Eclipse IDE preference pages to find something similar. Then go look at the code.

I almost always have my research workspace open as I’m developing applications. It’s like having an RCP code encyclopedia! Follow these steps to create one:

Read the rest of this entry »

There are many parts of RCP that are a little rough around the edges. That’s to be expected in an open-source framework, and to be honest it’s one of the things I like about RCP. Sure, commercial frameworks are cleaner and packaged more “professionally”, but they have to give up a lot of functionality and dynamism to achieve this.

But once in a while I hit a problem that just makes me go ugh! (and grrrr!). One of the best examples of this is the fact that if you don’t give an editor an icon, your editor won’t show up. If you happen to have logging turned on (and if your launch configuration does not include the -consoleLog parameter, it really should), you’ll at least get a somewhat informative message on startup:

!ENTRY org.eclipse.ui 4 4 2007-04-30 15:37:05.037
!MESSAGE Plugin com.marketcontours.ui.builder, extension org.eclipse.ui.editors
Required attribute 'icon' not defined

But you may not understand the true importance of this message until you try to open your editor. At that point you’ll more than likely get a very unhelpful NullPointerException, as the editor registry will simply return you a null editor.

I probably shouldn’t admit this (being a trainer and all), but I’ve actually had this happen to me repeatedly, and for some reason it always takes me a while to figure out what’s going on. It may have something to do with my failing to believe that omitting an icon could have this kind of effect. Also, in every class I teach, there is at least one student that hits this problem and is completely dumbfounded. I’m going to assume based on this random sample that many beginning RCP developers run into this.

There is already a Bugzilla entry for this defect (it’s actually listed as an enhancement), if you feel like voting for it.