An Overview of the Eclipse Infrastructure
- Jul 7, 2006
- Sample Chapter is provided courtesy of Addison-Wesley Professional
This chapter is from the book
Eclipse: Building Commercial-Quality Plug-ins, 2nd Edition
This chapter discusses the architecture behind the code generated in the previous chapter. Before diving deeper into every aspect of the program, it's time to step back and look at Eclipse as a whole.
The simple example plug-in that was started and described in Chapter 2—the Favorites plug-in—provides a concrete basis on which to discuss the Eclipse architecture.
3.1 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 3-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.
)
Figure 3-1 Eclipse plug-in structure.
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.
3.1.1 Plug-in structure
The behavior of every plug-in is in code, yet the dependencies and services of a plug-in (see Section 2.3.1, The Plug-in manifests, on page 71) are declared in the MANIFEST.MF and plugin.xml files (see Figure 3-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.
)
Figure 3-2 OSGilazy plug-in loadingExtension pointsusage exampleDeclaring a new extension.
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.
3.1.2 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 (see Section 3.4.4, Plug-in preferences, on page 116). 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 (see Section 3.4.3, Static plug-in resources, on page 115) and plug-in configuration files (see Section 3.4.5, Plug-in configuration files, on page 116) are shared by multiple workspaces.
Account Sign In
View your cart