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.

Share/Save

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.

Share/Save