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.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.