RCP Best Practices – Define products with feature based dependencies

Getting started

  1. Introduction
  2. Know where to get help
  3. Use RCP for the right reasons
  4. Use the correct version of RCP
  5. Use the correct tools
  6. Set up a target platform
  7. Mirror Eclipse repositories
  8. Create a product configuration
  9. Define products with feature based dependencies
  10. Remove versions from product dependencies
  11. Always run code using a product configuration
  12. Get your product building right away

Features and Plug-ins

As I mentioned in the last post, setting up a product configuration is one of the first things you should be doing when starting a new Eclipse RCP application. When you set up this product configuration you have a choice in how you define the product dependencies, meaning the set of the things that will be built and deployed with the product. Our choices here are plug-ins and features.

This choice is made on the Overview page of the Product Configuration editor, as you can see below.

Features are simply a way of referring to a set of plug-ins (I actually prefer the OSGi term bundles, but we’ll use plug-ins for now). So either way we’re defining a set of plug-ins that make up the product. So, you might ask, what’s the difference?

Features are the key to good RCP architecture

The proper use of features is a critical best practice that is essential to any non-trivial RCP application. This is especially true when you want to leverage the modularity of RCP in an enterprise of commercial setting. Any time you’re deploying varying sets of artifacts to different users or customers, features will be the mechanism that makes this work.

We’ll get into much more detail about features in later posts, but here is a short summary of why features are important.

  • Features provide an isolation layer so that you don’t need to depend on specific plug-ins. For example, each version of RCP is defined as a varying set of plug-ins – some are added, others are removed. If your product configuration simply depends on the feature org.eclipse.rcp, then you don’t have to worry about this. If you depend on the specific plug-ins, your product definition may break when you migrate to a new version of RCP
  • Features are the unit of reuse. I’m not sure how much grief I’m going to get for this, but I’ve come to the conclusion over the last few years that not only classes but plug-ins as well are too fine-grained to be an effective unit of reuse. From an architectural stand-point, it’s best to think of assembling our products from sets of features. I’ll come back to this in the future, but for now I’ll just say that it’s well worth spending time thinking hard about your feature definitions and how they may be used in a variety of situations.

Final thoughts

When you first create a new product, the default configuration is based on plug-ins. Change this right away. Initially, your product will be based on the org.eclipse.rcp feature and also your own feature which contains a single plug-in. From there you can start to build up your own features and add additional third-party features as required.