Feature based configuration of an RCP application

For a RCP application, I started with plugins based product configuration. When I reached a point where I need to provide software updates thru an update site, I needed a feature based product configuration. I thought should be as simple as selecting the features check box and adding the feature. But I spent around two whole days googling and debugging to bring it up and running. I think everyone would have gone thru the phase. I thought I'll write a blog entry on the issues, but I was lazy to draft such a long post. Yesterday Jan Kohnert sent a nice mail on his experience to the news group. Instead of copy-pasting the whole thing here, I present the information with little modifications. Thanks Jan.

• Open your product file and select features in the Overview tab:
  

• In the Configuration tab, click "New Feature...", and create the new feature:
  
  
• In the newly created feature, go to the included features tab and add "org.eclipse.rcp" feature:
  
• Go to the plugins tab and add your product's plugins
• RCP feature has most of the plugins that you would require. However if you use anything other plugins (core.resources, ui.forms, etc), you need to add those plugins to the feature:
  

At this point you should be successfully running your RCP application. If you are not interesting in providing support for Software Updates for your app, you should be fine with this.

Ideally, even for software updates, this should work fine. However, if you try to create an update site and try running software update, you will be hitting the java.lang.SecurityException: "Invalid signature file digest for Manifest main attributes". To get rid of that, remove the RCP feature from the included features list of your feature and add the plugins in RCP feature to your feature. Thanks to PDE team, copy-pasting works in the plugins tab of Feature Editor :-)



While going thru the update stuff, I realized that the update will not function as expected if we launch it from the IDE (Not sure of why). So I have to export the product and run from the disk, which means I can't debug and step thru the code :-( To know what happens during the update, I start the application with -debug options and add these lines in the .options file:

org.eclipse.update.core/debug=true
org.eclipse.update.core/debug/warning=true
org.eclipse.update.core/debug/parsing=true
org.eclipse.update.core/debug/install=true
org.eclipse.update.core/debug/configuration=true
org.eclipse.update.core/debug/type=true
org.eclipse.update.core/debug/web=true
org.eclipse.update.core/debug/installhandler=true
org.eclipse.update.core/debug/reconciler=true

Click here for more info on the .options

Debug your app

I don't have to explain the power of debugging and tracing thru the code. But it can happen only if you are executing your code locally. How can we debug a program which is executing in your customer's desktop? Logging is the solution. Although its not as powerful as debugging, it really helps in finding the bugs.

Eclipse provides a nice -debug command line option to switch on the logging mode. Shouldn't this option be -logging to avoid confusions? Don't ask me. I don't know :-P

The API Platform.inDebugMode() returns whether Eclipse is started with -debug or not. So in our code:

if(Platform.inDebugMode()){
System.out.println("My plugin is doing something");
}

When a customer has a bug, all he has to do is to start Eclipse with -debug option and send you the output. Simple? But the problem is your customer would have installed umpteen number of plugins and the log would literally be unreadable. How to enable logging for a specific plugin alone?

The .options file comes to rescue. This is a normal properties file, where you can specify the options including which plugins should be in debug mode and which are not. You can google for sample files.

Plugins are expected to look for this before printing the statement. So the above code should be:

if(Platform.inDebugMode() && Boolean.getBoolean(Platform.getDebugOption(Activator.PLUGIN_ID+"/debug"))){
System.out.println("My plugin is doing something");
}

Instead of repeating this if condition all over your plugin, you declare a field in your Activator and use it in other places:

public boolean inDebugMode = Platform.inDebugMode() && Boolean.getBoolean(Platform.getDebugOption(Activator.PLUGIN_ID+"/debug"));


and use it other places:

void foo(){
if(Activator.getDefault().inDebugMode()){
// debug mode
}
}