The Eclipse plug-in structure for Lotus Notes and Domino

The following is tip #1 from "Developing Eclipse plug-ins for Lotus Notes and Domino -- 7 tips in 7 minutes," excerpted from Chapter 3 of the book Eclipse: Building Commercial Quality Plug-ins, published by Addison-Wesley Publishing.

Structural overview

Eclipse isn't a single monolithic program, but rather a small kernel called a plug-in loader surrounded by hundreds (and potentially thousands) of plug-ins (see Figure 1) of which the Favorites example plug-in is one. Each plug-in may rely on services provided by another plug-in, and each may in turn provide services on which yet other plug-ins may rely.

This modular design lends itself to discrete chunks of functionality that can be more readily reused to build applications not envisioned by Eclipse's original developers.

Figure 1: Eclipse plug-in structure.

An example of how plug-ins depend on one another.

Plug-in structure

The behavior of every plug-in is in code, yet the dependencies and services of a plug-in are declared in the MANIFEST.MF and plugin.xml files (See Figure 2). This structure facilitates lazy-loading of plug-in code on an as-needed basis, thus reducing both the startup time and the memory footprint of Eclipse.

On startup, the plug-in loader scans the MANIFEST.MF and plugin.xml files for each plug-in and then builds a structure containing this information. This structure takes up some memory, but it allows the loader to find a required plug-in much more quickly, and it takes up a lot less space than loading all the code from all the plug-ins all the time.

Note: Plug-ins Are Loaded But Not Unloaded

In Eclipse 3.1, plug-ins are loaded lazily during a session but not unloaded, causing the memory footprint to grow as the user requests more functionality. In future versions of Eclipse, this issue may be addressed by unloading plug-ins when they are no longer required (see www.eclipse.org/equinox; and for more specifics on deactivating plug-ins see dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ equinoxhome/dynamicPlugins/deactivatingPlugins.html).

Figure 2: Declaring a new extension.

This is an example of how a new extension is declared in the plug-in manifest with lines highlighting how the plug-in manifest references various plug-in artifacts.

Workspace

The Eclipse IDE displays and modifies files located in a workspace. The workspace is a directory hierarchy containing both user files such as projects, source code, and so on, and plug-in state information such as preferences. The plug-in state information located in the workspace directory hierarchy is associated only with that workspace, yet the Eclipse IDE, its plug-ins, the plug-in static resources and plug-in configuration files (Plu) are shared by multiple workspaces.

Developing Eclipse plug-ins for Lotus Notes and Domino

 Home: Introduction
 Tip 1: The Eclipse plug-in structure for Lotus Notes and Domino
 Tip 2: The Eclipse plug-in directory for Lotus Notes and Domino
 Tip 3: The Eclipse plug-in manifest for Lotus Notes and Domino
 Tip 4: The Eclipse plug-in class for Lotus Notes and Domino
 Tip 5: The Eclipse plug-in model for Lotus Notes and Domino
 Tip 6: Eclipse logging for Lotus Notes and Domino
 Tip 7: Eclipse plug-in types for Lotus Notes and Domino