Structure Plug-ins and Dependent Libraries while implementing P2

Question

I am developing an RCP application and I am also implementing p2 updates for it.

I am using this link as guide to implement p2 updates.

For example I have 3 plug-ins A, B and C in my application.

Where Plugin A represent the core functionality of my application. Plug-in B is one more mandatory plugin. While plugin C is optional.

I have created 3 feature projects. Where FeatureA contains plug-in A and dependent libraries.

FeatureB contains plug-in B and dependent libraries. While FeatureC contains plug-in C and dependent libraries.

There are certain libraries which are common across these 3 plug-in e.g. birt, nattable. How should I structure them. Currently I am adding them in each feature project independently. What is the better way to structure feature projects? Kindly guide me.

Answer 1

When you have a common subset of plugins that your features require, you could make another "Requirements" feature which includes the required plugins and then require that feature in your existing features. This makes it easier for you to change your set of required plugins over time.

One downside of this approach is that Feature B may not need all of the plugins from the common feature which means if you ship Feature B without Feature A it could ship more plugins than you intend.

Another item you should consider is will you be updating the features independent of each other? If you require all versions of your features to be the same, then having the new Requirements feature makes sense. But if Feature A can upgrade to version 2.0 while Feature B remains at 1.0 you will encounter provisioning conflicts if you have singleton plugins.

One more thought is that since you're creating an RCP, you may just want to run the p2 publisher over your product file to produce a lineup IU. This produces much more deterministic provisioning of your RCP application. If you're creating a simple RCP which doesn't have the standard Eclipse About dialog, then you wouldn't even need to expose features.

As a final note, you could just buy update functionality. Having written this technology for the past 5 years I can tell you there are many pitfalls. My company's product, Secure Delivery Center, makes it easy to ship your software and includes simple update support.