>Building a Branded IDE

>One of the items that I’ve been searching for since I started with a eclipse is how to rebrand the eclipse IDE the correct way. There are programs and scripts like, Custom Eclipse Builder that allow building customized eclipse installations with various plugins and features. This however has several problems:

  1. Icons, Help, About, Introduction, etc. are all still the eclipse specific branding.
  2. With P2 if you install the SDK or another package, it overwrites your existing config.ini and replaces the information with it’s own. Thus re-branding your customized eclipse back to the original default.
  3. Executable is still named eclipse.

In some cases this isn’t so bad, and in actuality keeping scripts like Custom Eclipse Builder around can actually help ease the process of building a final product. However, you can build your own Branded version of eclipse with your own icons, and other features.

Product and Branding.

First thing to realize is that a branded IDE is nothing more than a really fancy RCP application. You will need to create a Product file for your application. More importantly though, you need to have a plugin that will be used by the product for branding purposes. It is this plugin that holds three key extension points.

  1. org.eclipse.core.runtime.products extension point. This will automatically be added to the plugin if you follow the PDE Wizard for creating a new Product. It contains a very important ID known as the product id. This MUST match up with what you entered during executing the product wizard. It also contains the application to start (more on this in a bit.)
  2. org.eclipse.ui.splashHandlers extension point. If you want your IDE to start up with a splash page and progress bars like the eclipse IDE, then you need to include this extension point, and the splashHandlerProductBinding, and splashHandler. You can leverage the existing eclipse splashHandler or make your own customized version.
  3. org.eclipse.ui.intro extension point. This allows your application to have a Welcome screen like the eclipse IDE. Add this extension point if you need something similar.

You’ll also need to make sure that your branding plugin’s plugin.xml file is included in your binary build, as well as add the plugin to a specific feature that will be included in your IDE. One of the items that you should do, is make sure that this particular plugin in the feature is set to Unpack. This way the launcher that is created can access the files for the branding during launch.

Configuring your IDE Product.

A product configuration is based entirely off of Features. So you will need to know the features that are needed by your product when it is to be built. You also need to setup a application for your product to use. The product Configuration editor allows you to easily edit all of this. For an IDE, you can use the org.eclipse.ui.ide.workbench application for your own product.

Feature wise, you will need at the very minimum the eclipse Platform Feature added to your configuration, along with any other features that your IDE depends on.

There are other options like Branding and Splash page information to fill out, but this gets you the basics. If everything is setup correctly, you can use the Product Export wizard to build your product, and you should have a Branded version of the eclipse IDE.


One of the issues I had when constructing the STAR Workbench’s XML IDE product build, was figuring out why I was getting, the infamous “Product cannot be found error” and the IDE wouldn’t start. This was caused because of the plugin.xml file that contained the product extension point wasn’t included in the binary build of the plugin.

Also, use the PDE Product Launch option, to make sure that your product can launch correctly from within the Eclipse workbench. Many other issues like missing features can be solved before hand using the launch configuration option from the Product Configuration.


It has always seemed to be a bit of undocumented magic, on how IDEs like Together, Rational Software Architect, and other eclipse based development environments were built. Hopefully this entry and the resources below will help shed some light on the topic, and remove some of the mystery on how it is done.


This entry was posted in eclipse, release engineering, xml. Bookmark the permalink.

2 Responses to >Building a Branded IDE

  1. Kevin says:

    >Great post Dave.The P2 issue is interesting through. Seems a problem of “who owns the config.ini”. Any thoughts on how we should address this?

  2. David Carver says:

    >Kevin, not sure. I need to do some more testing. I know that if you have just the Platform installed, and then you install the Eclipse SDK, the SDK takes over the config file. One way to handle this might be to separate out the features. So that the plugin that controls the branding and the config.ini is it’s own separate feature that might not necessarily be installable through an update site. If the application itself hasn’t changed then this should just bring down the SDK without updating the config.ini as well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s