1 / 15

ECLIPSE PLUGIN DEVELOPMENT

ECLIPSE PLUGIN DEVELOPMENT. Eclipse plug-in structure. 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. Plug-in declaration.

coye
Télécharger la présentation

ECLIPSE PLUGIN DEVELOPMENT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ECLIPSE PLUGIN DEVELOPMENT

  2. Eclipse plug-in structure 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.

  3. Plug-in declaration The Bundle-ClassPathdeclaration in the MANIFEST.MF file is a comma separated list describing which libraries (*.jar files) contain the plug-in code The Export-Package declaration is a comma-separated list indicating which packages within those libraries are accessible to other plug-ins The Require-Bundle declaration of the manifest to determine which other plug-insthus which classes will be visible to that plug-in during execution

  4. Extensions and extension points A plug-in declares extension points so that other plug-ins can extend the functionality of the original plug-in in a controlled manner. This mechanism provides a layer of separation so that the original plug-in does not need to know about the existence of the extending plug-ins at the time you build the original plug-in. Plug-ins declare extension points as part of their plug-in manifest, as in the views extension point declared in the org.eclipse.ui plug-in: <extension-point id="views" name="%ExtPoint.views" schema="schema/views.exsd"/>

  5. Plug-in preferences Plug-in preferences and other workspace-specific state information are stored in the workspace metadata directory hierarchy. For example, if Eclipse is installed at C:\eclipse and the default workspace location is being used, then the Favorites preferences would be stored in: C:/eclipse/workspace/.metadata/.plugins/com.qualityeclipse.favorites/pref_store.ini getPluginPreferences() Returns the preference store for this plug-in getStateLocation() Returns the location in the local filesystem of the plug-in state area for this plug-in savePluginPreferences() Saves the preference settings for this plug-in

  6. Plugin and AbstractUIPlugin All plug-in classes must implement the BundleActivator interface. Typically, UI-based plug-ins (plug-ins requiring the org.eclipse.ui plug-in) have a plug-in class that subclasses AbstractUIPlugin, while non-UI plug-ins subclass Plugin. Both classes provide basic plug-in services for the plug-in programmer, but there are important differences.

  7. Plug-in Model- Platform The org.eclipse.core.runtime.Platform class provides information about the currently executing Eclipse environment. Using this class, you can obtain information about installed plug-ins, extensions, extension points, command line arguments, job manager, installation location, and more.

  8. Plug-in Model-Plug-ins and Bundles Information about the currently installed plug-ins, also known as Bundles, can be obtained using Platform.getBundleGroupProviders() or Platform.getBundle(String). Accessing a plug-in class, also known as a bundle activator, requires the containing plug-in to be loaded whereas interacting with the Bundle interface does not carry such a penalty.

  9. Plug-in Model- Plug-in extension registry You can access the plug-in extension registry using the Plaform.getExtensionRegistry() method. It contains plug-in descriptors, each representing a plug-in. The registry provides the following methods for extracting information about the various plug-ins without loading them getConfigurationElementsFor(String extensionPointId) Returns all configuration elements from all extensions configured into the identified extension point. getExtensionPoint(String extensionPointId) Returns the extension point with the given extension point identifier in this plug-in registry.

  10. Plug-in Model- Logging /** * Returns the log for this plug-in. If no such log exists, one is created. * * @return the log for this plug-in * XXX change this into a LogMgr service that would keep track of the map. See if it can be a service factory. */ public final ILoggetLog() { return InternalPlatform.getDefault().getLog(bundle); }

  11. Plug-in Model- Status objects The IStatus type hierarchy in the org.eclipse.core.runtime package provides a mechanism for wrapping, forwarding, and logging the result of an operation, including an exception if there is one.

  12. SWT

  13. JFace JFace list viewers, such as ListViewer, TableViewer, and treeViewer, allow you to directly use your domain model objects without needing to manually decompose them into their basic string, numerical, and image elements. The viewers do this by providing adapter interfaces for such things as retrieving an item's label (both image and text), for accessing an item's children (in the case of a tree), for selecting an item from a list, for sorting items in the list, for filtering items in the list, and for converting an arbitrary input into a list suitable for the underlying SWT widget.

  14. Jface-Relationship between viewers and adapters

  15. IAction versus IActionDelegate An Eclipse action is composed of several parts, including the XML declaration of the action in the plug-in's manifest, the IAction object instantiated by the Eclipse UI to represent the action, and the IActionDelegate defined in the plug-in library containing the code to perform the action

More Related