equinox |
The Plug-in Registry |
When the Eclipse Platform starts, it first discovers all available plug-ins
and fragments. The install/update component of Eclipse and a user-defineable
plug-in path are used to determine directories where to plug-ins and fragments
can be found. Each plug-in/fragment directory may contain exactly one manifest
file named plugin.xml or fragment.xml. If a directory contains
both files, only the plugin.xml file is used.
Once the discovery is completed, the platform parses the discovered manifest files and builds a plug-in registry. Manifests which cannot be loaded are skipped and the failure is noted in the platform's log (typically under the <workspace>/.metadata directory). The registry is then resolved. That is, it is examined to ensure the structure is useful and sane, and its structures are cross linked. Resolution includes the following steps:
An error message is logged if any problems are encountered and the offending element is removed from the plug-in registry. This allows Eclipse to continue running even if there are minor problems. The resulting plug-in registry is available via the org.eclipse.core.runtime plug-in's API. The whole plug-in registry is available through IPluginRegistry and individual plug-ins can be examined with IPluginDescriptor.
Because these plug-ins define the running Eclipse, additions, deletions or modifications of plug-ins are not detected after start-up. Eclipse must be shut down and restarted to detect these changes.
Plug-in Activation |
When Eclipse starts up, only those plug-ins needed to build the plug-in registry and get things started are activated. All other plug-ins (the vast majority of plug-ins) remain dormant. When something happens causing the code within a plug-in to be loaded, that particular plug-in is activated. That is, classloading is the only trigger for plug-in activation. Plug-ins are only activated if the class loaded comes from the plug-in's local classpath (i.e., one of its libraries). Loading classes from a prerequisite does not count. This is the basis for Eclipse's lazy plug-in activation policy.
Many things can happen without activating a plug-in. In particular,
Once a plug-in is activated it remains active until Eclipse shuts down. When Eclipse does shut down, all plug-ins are shut down in a dependents-first order. For example, if plug-in A requires plug-in B, then plug-in A will be shut down before plug-in B.
Plug-in Classloading |
Libraries define the local classpath of a plug-in. Each library entry translates into an entry on the classpath of the plug-in's classloader. Earlier we discussed the concept of a code vs. a resource library. Resource libraries are loaded by a resource loader and do not figure into the strict classloading model.
Classloading in Eclipse follows the P-S-P model. That is, Parent-Self-Prerequisites.
Note that prerequisite consultation is transitive. When locating a class, a prerequisite plug-in will follow the same (though optimized) P-S-P model. Since all plug-in classloaders have the same parent, prerequisite loaders need not look there. Similarly, plug-ins which occur repeatedly in the transitive closure of the prerequisite graph are consulted at most once. Finally, prerequisite re-exporting rules are followed as described above.
Plug-in Data |
The Eclipse Platform makes certain assumptions about the physical structure of a plug-in. Each plug-in or fragment is typically stored in a separate directory under a directory named plugins under your Eclipse install directory. The name of this directory is usually the same as the plug-in's id (though it may have the version number appended to it). In addition to the plugin.xml or fragment.xml file, there may be any number of folders under the plug-in's root folder.
Since Eclipse can be run on a wide range of machine configurations (i.e., operating system, window system, ...) it needs a way of managing different forms of the same data (e.g., shared libraries). Eclipse provides four variables for use in library statements which resolve to parts of the current machine configuration.
So, for example, if your plug-in uses windowing system-specific features, it may be necessary to provide a different library for each configuration. Using $ws$/<library name> in your plug-in manifest file directs Eclipse to look for the library in a window system directory with the same name as the current window system. The org.eclipse.swt plug-in uses this mechanism as follows:
<runtime> <library name="$ws$/swt.jar"> <export name="*"/> </library> </runtime>
The SWT plug-in has a series of directories of the form ws/<windowing system>/ (e.g., ws/win32, ws/gtk, ws/motif). Each of these directories contains a different version of swt.jar. If you are working in an Eclipse environment in a win32 windowing system, the library name $ws$/swt.jar will match ws/win32/swt.jar. Note that in practice any given Eclipse install will have only one swt.jar (the one that matches the install). The jars are actually contributed by window system-specific fragments. This allows the common part of a plug-in to be put in the plug-in and have only the window system code in a fragment.
Registry Life Cycle |