Книга: Embedded Linux development using Eclipse

1.4.5 Plug-Ins

1.4.5 Plug-Ins

A plug-in is the smallest unit of Eclipse functionality that can be developed and delivered separately. A small tool is usually written as a single plug-in, whereas a complex tool may have its functionality split across several plug-ins. Except for a small kernel known as the Platform Runtime, all of the Eclipse platform’s functionality as described above is located in plug-ins.

Plug-ins are coded in Java. A typical plug-in consists of Java code in a JAR library, some read-only files, and other resources such as images, web templates, message catalogs, native code libraries, etc. Some plug-ins don’t contain code at all. An example is a plug-in that contributes online help in the form of HTML pages. A single plug-in’s code libraries and read-only content are located together in a directory in the file system or at a base URL on a server.

Each plug-in’s configuration is described by a pair of files. The manifest file, manifest.mf, declares essential information about the plug-in to other plug-ins, including the name, version, and dependencies. The second optional file, plugin.xml, declares the plug-in’s interconnections to other plug-ins. The interconnection model is simple: a plug-in declares any number of named extension points, and any number of extensions to one or more extension points in other plug-ins.

The extension points can be extended by other plug-ins. For example, the workbench plug-in declares an extension point for user preferences. Any plug-in can contribute its own user preferences by defining extensions to this extension point.

On start-up, the Eclipse runtime discovers the set of available plug-ins, reads their manifest files, and builds an in-memory plug-in registry. The platform matches extension declarations by name to their corresponding extension point declarations. Any problems, such as extensions to missing extension points, are detected and logged. The resulting plug-in registry is available via the Platform API. After startup, plug-ins can be unloaded, and new ones installed or new versions of existing plug-ins can replace existing versions.

By default, a plug-in is activated when its code actually needs to be executed. Once activated, a plug-in uses the plug-in registry to discover and access the extensions contributed to its extension points. For example, the plug-in declaring the user preference extension point can discover all contributed user preferences and access their display names to construct a preference dialog. This can be done using only the information from the registry, without having to activate any of the contributing plug-ins. The contributing plug-in will be activated when you select one of its preferences from a list.

By determining the set of available plug-ins up front, and by supporting a significant exchange of information between plug-ins without having to activate any of them, the platform can provide each plug-in with a rich source of pertinent information about the context in which it is operating. The context doesn’t change while the platform is running, so there’s no need for complex life cycle events to inform plug-ins when the context changes. This avoids a lengthy start-up sequence and a common source of bugs stemming from unpredictable plug-in activation order.

Оглавление книги