Create patches for Eclipse3.4 RCP applications

Introduction: After the release of the product, often need to provide users with some temporary or small patches to correct users in the use of the problems encountered. Feature Patch is a flexible way to implement plug-in updates, and this article focuses on how Equinox-based RCP can create, deploy Feature Patch, and provide solutions to the problems that arise after deployment.

If a user discovers a problem in the product during use, a solution for developers is to include changes to these issues in the next release. However, if the problem is very urgent and even affects the customer's normal work, the usual practice is to create a temporary patch and then install it into the user's production environment. For an Eclipse based RCP product, the upgrade of the product is the improvement of the plug-in functionality, that is, the plug-in version. After creating a new version of the plug-in, how to pay the user? One way is for the user to specify the update Site for installation through the Software update interface. But this mechanism is cumbersome for commercial products or small changes to products, and because the product environment is customized by the installation software, the installation may not be completed through the Software update interface. This paper introduces a general method to create and deploy Feature Patch, which can be more flexible to solve the problem.

The concept of Feature and Feature Patch

Plug-in (plug-in, OSGI bundle) contains the specific implementation of product functionality, but from the perspective of the entire product granularity is small, not conducive to management. Feature (functional components) can be similar to the function of the plug-ins organized, user management is a functional module, and do not need specific implementation details, so that the entire structure of the product hierarchy. By using Feature to package plug-ins, you can do this:

1. List all prerequisites to facilitate Eclipse's configuration management

2. Use Eclipse Software update to manage Plug-ins

3. Support branding management, you can define a welcome page in feature, so that users are more familiar with the functions of plug-ins.

Although a simple copy Plug-in to eclipse's Plugins directory can take effect, these plug-ins are not managed, and this practice is not recommended. At the same time, if the Eclipse based RCP is configured to install and upgrade based on Feature, then only a high version of the plug-in is generated and copied, and for this scenario, a patch is required to be created in Feature Feature Patch.

Feature Patch is an engineering type that eclipse supports, similar to the Feature engineering structure, does not actually participate in the Eclipse startup process, and specifies which Patch to create patches in Feature Feature, featuring

Generally small, and you must specify which Feature to create a patch

Feature Patch only contains plug-ins that need to be updated, and only some of the plug-ins that already exist Feature are updated after deployment

To simplify the patch mechanism, this article takes an incremental patch, whereby each feature contains only one feature patch program. For example, assuming that Feature a already contains patch B, the next release of the patch should contain the modifications in patch B.

Version specification for Eclipse Plug-ins

During the creation of the Feature patch, the version of the plug-in is changed, which requires the reader to understand the version specification of the plug-in. The plugin names in the Eclipse/plugins directory are mostly Org.eclipse.equinox.p2.engine_1.0.4.v20080930.jar similar structures, where Org.eclipse.equinox.p2.engine the ID of this plug-in, and the version number of this plug-in after the underscore. In Eclipse, the version number of a plug-in is made up of four parts: Major.minor.service.qualifer

Table 1. Eclipse Plug-in version specification

Partial name	When do you change?
Major	When the API of the product changes greatly, the major part should be increased and the minor and service parts should be 0 when the major part changes.
Minor	"Externally visible" changes, such as important performance improvements, major code rewriting
Service	Plug-ins change between different release versions, such as Bug fix in code, compilation option settings change
Qualifier	Changes between different builds