RCP Best Practices – Remove versions from product 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

The problem with feature versions in products

There are many places in an Eclipse RCP application where version constraints can be used. We can constrain bundle dependencies as well as feature dependencies, and it’s important to make proper use of these constraints. But occasionally we may create constraints that are not very useful, and in my opinion this is the case with product dependencies.

First, when you add a feature to a product configuration on the Dependencies page of the editor, the current version of that feature is recorded.

If you leave the feature version as it is, this is the only version of that feature which will work with your product. In this case, for example, if you upgrade your target platform to reference RCP 4.2.2 (when it comes out), your product will break.

Your product build will fail because of the unresolved version constraint. Also, if you’re running in the IDE using the link on the Overview page of the product configuration editor, your application will crash with a not very helpful error message.


!SESSION Thu Nov 01 10:30:49 PDT 2012 ------------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2012-11-01 10:30:49.026
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

Removing feature version constraints

The solution is to remove these feature version constraints. This is easily done in the editor by selecting the recently added feature and clicking the Properties button on the right. Then simply select the entire version text and delete it.

Your product will now build and run with whatever feature version that is available in the target platform.

So where do the versions go?

You may be thinking that by removing these version constraints we’re opening the door to future problems. That’s a very good thought to have, as managing feature dependencies can be a complicated business. Remember, though, that product configurations are about building things. The purpose of these feature versions is to create a reproducible build against a specific feature set.

In my opinion, the best way to achieve this is to specify the feature versions in the target definition file to be used in the build. These target definition files can be checked in to a VCS, tagged and branched to your hearts content. This allows for repeatable builds against a specific set of feature versions without the hassle of hard coding the versions in the product.