RCP Best Practices – Set up a target platform

Getting started

When you start work on a new RCP project, one of the first things you should do is set up a target platform. I usually create a target platform before I create any other project.

What is a target platform?

In every software project, there are two types of code:

First, there is the code you write. This is usually represented by a set of projects in your workspace.
Second, there is the code you are reusing. This might be common libraries such as Log4. It would certainly include the core RCP bundles. It may also include upstream dependencies you have in your own organization (frameworks, utilities, etc.).

This second type of code is our target platform.

How do I set up a target platform?

Target platforms are created using a target definition file. For Tycho build purposes, target definition files should always be stored in a separate project. So the first step is to create a project called something like com.mycompany.myapp.target. This can be just a simple project, not a Java or Plugin project.

Inside this project, create a target definition file. I’m not going to go into detail on this (you can get more info here). I will make a few suggestions, though.

Target locations should always be p2 repositories

Target definitions point to sets of features and bundles which will be available to your application. It’s possible to point target definitions at folders on your filesystem or even Eclipse installations, but this is not a good idea. Ideally, all of your target locations will be Software Site locations, meaning they point to p2 repositories. This is especially important for setting up Tycho builds.

Carefully select initial target features

Your target platform will define the set of features and bundles which may be shipped with your application. Whether they will or not depends on your feature and product definitions, as we’ll see in later posts.

To start with, though, your target should at least contain the RCP SDK feature (for either RCP 3 or 4). This will guarantee you have the base bundles needed to ship an RCP application along with the source bundles you need to debug and browse the RCP source code.

You may also (especially if you’re working with RCP 3), want to step up to the Eclipse Platform SDK feature. This is useful if you want to add in other platform functionality such as the Forms API or the Common Navigator. Note that the Platform SDK feature will also bring in the RCP SDK feature, so you don’t have to list them both.

Behond the Platform or RCP SDK features, you can then add whatever else you need. GEF, EMF, whatever you require. To consume your own upstream dependencies, you will want to point at internal p2 repositories holding your own snapshot or release builds. For those of you familiar with Maven builds, this functions in a similar way to internal Maven repositories.

Finally, if you’re doing unit testing you’ll want to add the PDE JUnit Runner Support – Add-on feature. This will provide the bundles needed to create and run unit tests on your code. For some reason, this feature is not included in the main releases repositories.

http://download.eclipse.org/releases/juno

You need to go to an updates repository, such as

http://download.eclipse.org/eclipse/updates/4.2

Here are some sample targets you can use to get started. Right-click on the link to download the target you want.

Final thoughts

Properly managing your target platform is one of the keys to successfully using RCP. There are many other points to make related to target platforms, and I’ll be coming back to this topic repeatedly in future posts. But for now my point is that using a correctly defined target platforms is one of the most important best practices I can think of.