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.
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.
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.
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
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
This chapter is excerpted from Eclipse: Building Commercial-Quality Plug-ins, 2nd Edition, by Eric Clayberg and Dan Rubel, published by Addison-Wesley Professional in March 2006. Copyright 2006 Pearson Education Inc. ISBN: 032142672X. Reprinted with permissions, all rights reserved. Click here to see a complete Table of Contents for this book. Click here for the chapter download.
This was first published in April 2007