Section 23.3.  Product Configurations

23.3. Product Configurations There are two types of Eclipse product configurations: standalone and extension. The hospital scenario requires both. Standalone products are "traditional" RCP applications and have been the focus of this book. Hyperbola's typical configuration is as a standalone application. It has its own entry point (i.e., an IPlatformRunnable and an application extension point), a WorkbenchAdvisor, a product extension, and other product-level branding such as a splash screen and a customized launcher. This type of product is used at the nursing station, on administrator desktops and kiosks, and in PDAs. By contrast, an extension product is one intended to extend an existing standalone product. As such, extension products do not have an application entry point or the same degree of customization typically associated with a standalone productextension products do not have their own WorkbenchAdvisors. This configuration is used for the hospital's developers and other tool-based workers who are already using another Eclipse-based product such as the Eclipse IDE. One of the selling points of Hyperbola in this scenario is that Hyperbola can simply be integrated with other Eclipse-based applications as the hospital's needs expand. Figure 23-1 shows how common groups of plug-ins, called framework plug-ins, are used in combination with product-specific plug-ins to build both extension and standalone product configurations. The various configurations share a common set of framework plug-ins and optionally add their own customization plug-ins to the mix. Most of the function of the product lives in the framework plug-ins and is reused in all product configurations. The trick is deciding what to include in the framework plug-ins and what to put in the product configurations. Figure 23-1. A product with several product configurations [View full size image] Supporting a wide range of product configurations is a very powerful advantageit gives your product more exposure and provides users with access to your product when and where they need it. This sounds great on paper, but in reality, creating a fully configurable product suite is easiest if you make it an explicit design objective. Like any software system, if reuse is not a concern, the code will not be reusable. The essence of promoting reuse is the ability to split Hyperbola into several configurations that run in different environments but share as much code as possible. This section looks at restructuring Hyperbola as several plug-ins. We detail what goes in each plug-in, plug-in naming conventions, and implications on building and packaging. The rest of the chapter then builds on this refactoring and describes and compares Hyperbola configurations for the different execution environments. 23.3.1. Restructuring Hyperbola The best way to understand the restructuring of Hyperbola is to contrast the prototype structure built in Part II with the multi-configuration structure developed here. Figure 23-2 shows the Hyperbola plug-in structure in the prototype. The product information is embedded in the monolithic Hyperbola plug-in that includes the advisors, the product description, and the basic messaging infrastructure. This is a natural organization that is easy to understandperfect for a prototype. Figure 23-2. Hyperbola that supports one product configuration [View full size image] Figure 23-3 shows Hyperbola after being restructured to support multiple configurations. The figure shows framework plug-ins and product configurations. The framework plug-ins contain the Hyperbola application logic, Contacts view, and Chat editor, with all product-specific files and code removed. Figure 23-3. Hyperbola that supports multiple product configurations [View full size image] Product configurations pull together the product-specific and common parts of Hyperbola to run in a particular environment. They typically include some number of product plug-ins that coordinate and position the various elements defined in the framework. The configurations also include features that capture the complete set of required plug-ins. The key point here is that the UI components and actions are implemented once and then reused in different product configurations. The benefits cannot be over-estimated. As the rest of this chapter highlights, this approach clarifies the structure of the system and enables the use of your function in vastly different scenarios. The amount of code specific to individual configurations is kept to a minimum and sometimes is completely eliminated. 23.3.2. Hyperbola Projects There are three basic configurations of Hyperbola at the root of the four execution environments in the hospital scenario: Workbench A standalone product that includes the UI Workbench. JFace A standalone product that relies only on JFace. IDE An extension product that plugs into an existing Eclipse IDE. These configurations can be tweaked and parameterized to fit all the use cases outlined above. For example, both the desktop and kiosk requirements can be met using the Workbench configuration. Before digging into that, let's look at the basic configurations. Figure 23-4 shows the Hyperbola feature and plug-in projects needed to support all of the hospital's requirements. Figure 23-4. Hyperbola projects with support for multiple product configurations 23.3.3. Project Naming This list looks daunting at first, but makes sense once you understand the naming convention. The word "product" is used in a name to identify plug-ins that adapt infrastructure pieces to product configurations (e.g., the org.eclipsercp.hyperbola.product.workbench plug-in contributes the actions and views for Hyperbola as a regular RCP standalone application). As we mentioned in Section 14.3, "Defining Features," and Chapter 21, "Installing and Updating Plug-ins," the word "feature" is used to distinguish feature projects from all others. Again, the challenge here is that the feature and plug-in namespaces are separate, so technically, you can have plug-ins and features with the same name. This, of course, would be very confusing, not to mention the difficulty of managing plug-in project names in the workspace. Finally, the framework or infrastructure plug-in names have unqualified names that reflect their functional content (e.g., org.eclipsercp.hyperbola.ui contains a generic UI function for Hyperbola). This naming convention may not suit your environment, but it has been useful in the development of Hyperbola and in helping explain the structures in this book. 23.3.4. Why So Many Projects? You may still be asking why there are so many projects. The short answer is that each exists because either there is a need for reuse of that function or there is a corresponding product configuration defined by that project. This leads to our first rule: Rule 1: Top-level featureHave a top-level feature and plug-in for every product configuration. Following this rule allows you to describe the complete set of plug-ins required for each product configuration in a form that is clear, complete, and understood by various parts of the Eclipse tooling. There are several other benefits to this approach: Simply exporting the feature is one way to package the configuration. The feature or root plug-in also serves as an anchor point for creating product definitions (.product files). Features are required if you plan to use the Eclipse Update Manager in your deployments. Features are also required if you want to use PDE's automated build mechanisms. A top-level plug-in serves as the home for the feature branding content. Underneath these top-level structures, Hyperbola's feature set is factored into as many reusable features as needed. Don't go overboard or there will be one feature for every plug-in. Remember, features are lists of plug-ins to build or deploy togetherthey are an abstraction to help you structure and manage your world. If you have 100 plug-ins that always go together, one feature should suffice. On the other hand, if you want to manage only handfuls of plug-ins at a time, use more features. Go back now and look at the list of projects in Figure 23-4 and compare it to the structure shown in Figure 23-3there is a project in the list for every element in the structure diagram. This is a simple and straightforward approach.