Eclipse RCP Cookbook Part I
In this article I will tell you what the Eclipse Rich Client Platform, how it works and what it is. Please note, if you are looking for a tutorial on how to create your RCP, you here, I want to tell you how it works from the inside.
To consider the entire Eclipse RCP with his long history in one post is almost impossible, so for starters I would like to highlight the main concept of the platform such as the workspace (workbench), plugins, dependencies and runtime.
/ > In the text I will indicate references to useful literature, in particular, in article
Larsa Vogella, he is a recognized speaker in the world of Eclipse technology, and a multiple award-winning community of Eclipse.
Eclipse is an extensible platform for building IDES. The platform is expanded with plug-ins, each of which can complement the behavior of Eclipse. For example, adding new editors, menu items, etc.
Workspace (workbench) is the root element of the graphical representation of the Eclipse platform. It can contain one or more Windows (workbench window), which provides the user with a certain model. Most often it is the resources stored in the workspace (workspace). To open a new window using Window > New Window.
Each window contains a collection of pages (workbench page) and a link to the live page, only one page can be active in a single window.
Editors (editors) and (views) are stored in the page with the appropriate managers (ViewFactory, EditorManager). The editors and types have a common interface — IWorkbenchPart, then the working part. Workspace does not store references to the editors and the types and uses of intermediate objects EditorReference and ViewReference. This allows you to load plugins using lazy initialization (lazy initialization). For example, the following screenshot plug-ins that define the types of Hierarchy, Javadoc and Declaration, may not yet be loaded, as long as not used.
Views and editors are very similar to each other, they together are the parts of the page have the same mechanism for creating menus and buttons, they both can display the contents of several files, but still between them there are conceptual differences. Multiple editor instances can be created on one page, unlike the species. Editors can display the status change of the file (dirty) indicate that there are unsaved changes may be lost if you close the editor without saving.
The page also contains multiple perspectives (perspective). Perspective is a template page that contains a collection of parts, and their relative positions on the page, keyboard shortcuts for commands, appearance, menus and more. To customize a perspective, you can use the command Window → Customize Perspective.
Information about user settings are stored in the directory [workspace]/.metadata/.plugins/org.eclipse.ui.workbench/. With these files you can use your settings perspectives in different workspaces. However, it is better to use the option of copy settings when switching workspaces.
Read about workspace SDAs and more here.
A plugin is a component that provides a particular service within the context of the workspace. An example plugin can be org.eclipse.debug.core, which allows the developer to debug their programs, and org.eclipse.debug.ui, which contains the graphical representation for the first.
Description of the plugin takes place in a special XML file — plugin.xml lying in the plugin folder. This file describes how the plugin extends the Eclipse platform (described by the editors, types, context menu), how he does it will be described in section Dependencies. Code implementation of the plugin will be loaded only when the plugin starts, again lazy initialization. So Eclipse can display the extension of the plugin without downloading it directly.
Example plugin.xml presented in the article "What is the plug-in manifest file (plugin.xml)?"
the
The Eclipse runtime provides the functionality responsible for controlling the lifecycle of the plugin. The plugin will be loaded only when necessary, and similarly disabled. Within a running eclipse instance will be created (instance) of the plug and the point of interaction is the plugin class (org.eclipse.core.runtime.Plugin), it is called an activator. The main function of the activator is to generate additional actions during the start of the plugin (initialization of images, caching of certain static resources, etc.). If there is no need to perform additional actions, it is possible not to specify the activator and will be used standard. Learn more about activator read SDAs. Runtime Eclipse implementing the OSGi specifications.
OSGi (Open Services Gateway Initiative) is a specification that allows to divide a complex system into modules (bundles), and to remotely install, update or remove the modules without rebooting the system. Each module has a set of dependencies on other modules and a well-defined API for interaction with other modules.
Technically, a module is .jar file, which contains additional meta information that is stored in META-INF/MANIFEST.MF module this file is part of the specification of the jar file. The runtime environment is different from OSGi will ignore these files.
Also in OSGi-described components, such as bundle, service, life-cycle, services registry, and so on. OSGi architecture looks like the following:
In addition to Eclipse, OSGi has several other implementations such as Apache Felix, Knopflerfish, Concierge OSGi and others. Learn more about OSGi, read on official website, wiki and Lars.
The implementation of OSGi in Eclipse is a philosophical name Equinox. Therefore, the plug-in is an OSGi module, and its meta information as follows.
the
Equinox is responsible for managing the dependencies between modules at runtime. It reads the MANIFEST.MF module during installation and make sure all dependent modules are already loaded, and then activates the requested module. If the dependencies are not found, the module will not boot. If the module is trying to appeal to the class without dependence on him, ClassNotFoundException will be thrown.
OSGi is available for activation plug-ins that are located in a separate plugins folder eclipse_install_dir/plugins.
Perform this role dependent and required plugins. Classic video describes dependence in the meta-date of the plug-in MANIFEST.MF.
Dependence is not determined only at runtime, but a compile time option. During the execution of Eclipse make sure that all required dependencies are available to the dependent module and then only activates it. During the Eclipse compile classpath accordingly modifies the dependent plug-in.
One of the most common and the dependencies used in Eclipse is called "extension points" (extension points). Point is used to extend (extension) of the functional host with many other plugins without direct dependence on him. Extensions and extension points are described in the description file of the plugin plugin.xml.
A good example of extension points is the network of power: an extension point is a plug socket, which can connect to other elements of the grid (lamps, computers, irons) that extend the functionality of the mains. Each device must have a device coordination with the power supply network, otherwise connect it can't.
Continuing the examples, the org.eclipse.ui describes the set of extension points such as editors, "types", "menu". There are other plugin org.eclipse.help.ui that adds your menu item "Help- > Help Contents". To this end, it describes the following extension.
the
If there were some strange moments with extension points, we suggest that to understand since the mechanism is essential for the interaction of the plugins.
So read here, here and more in detail with examples SDAs. A list of extension points of the platform are presented SDAs.
Plug-ins, except that can use existing extension points can define a new one. Points are described using *.exsd and the corresponding extension tag-point with reference to the description file.
the
This file will describe the interface extension to the host, namely the required data and/or classes that implement certain interfaces.
Read more about creating your own extension points again at Lars and here.
General Eclipse Programming
Eclipse 4 RCP — Tutorial from Lars Vogel
Eclipse Rich Client Platform (2nd Edition)
Top 10 mistakes in Eclipse Plug-in Development
Eclipse Platform
How to Use the Eclipse API
Notes on the Eclipse Plug-in Architecture
Eclipse UI
Inside the Workbench
Eclipse User Interface Guidelines
If the public wants to know more about Eclipse as a platform for developing applications, I could continue writing articles and shed light on the following technologies
the
However, first and foremost, I would like to know what interesting You might delve into the theory — development tools, their concepts, features, or conduct a series of tutorials, which will create a Eclipse plugin, and in parallel let us consider the theoretical aspects of development (idea, what the plugin You are missing in Eclipse are welcome).
Article based on information from habrahabr.ru
Introduction
To consider the entire Eclipse RCP with his long history in one post is almost impossible, so for starters I would like to highlight the main concept of the platform such as the workspace (workbench), plugins, dependencies and runtime.
/ > In the text I will indicate references to useful literature, in particular, in article
Larsa Vogella, he is a recognized speaker in the world of Eclipse technology, and a multiple award-winning community of Eclipse.
Eclipse
Eclipse is an extensible platform for building IDES. The platform is expanded with plug-ins, each of which can complement the behavior of Eclipse. For example, adding new editors, menu items, etc.
workspace
Workspace (workbench) is the root element of the graphical representation of the Eclipse platform. It can contain one or more Windows (workbench window), which provides the user with a certain model. Most often it is the resources stored in the workspace (workspace). To open a new window using Window > New Window.
Each window contains a collection of pages (workbench page) and a link to the live page, only one page can be active in a single window.
Editors (editors) and (views) are stored in the page with the appropriate managers (ViewFactory, EditorManager). The editors and types have a common interface — IWorkbenchPart, then the working part. Workspace does not store references to the editors and the types and uses of intermediate objects EditorReference and ViewReference. This allows you to load plugins using lazy initialization (lazy initialization). For example, the following screenshot plug-ins that define the types of Hierarchy, Javadoc and Declaration, may not yet be loaded, as long as not used.
Views and editors are very similar to each other, they together are the parts of the page have the same mechanism for creating menus and buttons, they both can display the contents of several files, but still between them there are conceptual differences. Multiple editor instances can be created on one page, unlike the species. Editors can display the status change of the file (dirty) indicate that there are unsaved changes may be lost if you close the editor without saving.
The page also contains multiple perspectives (perspective). Perspective is a template page that contains a collection of parts, and their relative positions on the page, keyboard shortcuts for commands, appearance, menus and more. To customize a perspective, you can use the command Window → Customize Perspective.
Information about user settings are stored in the directory [workspace]/.metadata/.plugins/org.eclipse.ui.workbench/. With these files you can use your settings perspectives in different workspaces. However, it is better to use the option of copy settings when switching workspaces.
Read about workspace SDAs and more here.
Plugin
A plugin is a component that provides a particular service within the context of the workspace. An example plugin can be org.eclipse.debug.core, which allows the developer to debug their programs, and org.eclipse.debug.ui, which contains the graphical representation for the first.
Description of the plugin takes place in a special XML file — plugin.xml lying in the plugin folder. This file describes how the plugin extends the Eclipse platform (described by the editors, types, context menu), how he does it will be described in section Dependencies. Code implementation of the plugin will be loaded only when the plugin starts, again lazy initialization. So Eclipse can display the extension of the plugin without downloading it directly.
Example plugin.xml presented in the article "What is the plug-in manifest file (plugin.xml)?"
the
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
<extension
point="org.eclipse.ui.views">
<view
class="com.xyz.myplugin.ViewPart"
id="com.xyz.myplugin.testview"
name="Test View">
</view>
</extension>
</plugin>
runtime
The Eclipse runtime provides the functionality responsible for controlling the lifecycle of the plugin. The plugin will be loaded only when necessary, and similarly disabled. Within a running eclipse instance will be created (instance) of the plug and the point of interaction is the plugin class (org.eclipse.core.runtime.Plugin), it is called an activator. The main function of the activator is to generate additional actions during the start of the plugin (initialization of images, caching of certain static resources, etc.). If there is no need to perform additional actions, it is possible not to specify the activator and will be used standard. Learn more about activator read SDAs. Runtime Eclipse implementing the OSGi specifications.
OSGi (Open Services Gateway Initiative) is a specification that allows to divide a complex system into modules (bundles), and to remotely install, update or remove the modules without rebooting the system. Each module has a set of dependencies on other modules and a well-defined API for interaction with other modules.
Technically, a module is .jar file, which contains additional meta information that is stored in META-INF/MANIFEST.MF module this file is part of the specification of the jar file. The runtime environment is different from OSGi will ignore these files.
Also in OSGi-described components, such as bundle, service, life-cycle, services registry, and so on. OSGi architecture looks like the following:
In addition to Eclipse, OSGi has several other implementations such as Apache Felix, Knopflerfish, Concierge OSGi and others. Learn more about OSGi, read on official website, wiki and Lars.
Equinox
The implementation of OSGi in Eclipse is a philosophical name Equinox. Therefore, the plug-in is an OSGi module, and its meta information as follows.
the
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Test Plug-in
Bundle-SymbolicName: com.xyz.myplugin; singleton:=true
Bundle-Version: 1.0.0
Bundle-Activator: com.xyz.MyPlugin
Require-Bundle: org.eclipse.ui
org.eclipse.core.runtime
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Equinox is responsible for managing the dependencies between modules at runtime. It reads the MANIFEST.MF module during installation and make sure all dependent modules are already loaded, and then activates the requested module. If the dependencies are not found, the module will not boot. If the module is trying to appeal to the class without dependence on him, ClassNotFoundException will be thrown.
OSGi is available for activation plug-ins that are located in a separate plugins folder eclipse_install_dir/plugins.
Dependencies
Direct correlation
Perform this role dependent and required plugins. Classic video describes dependence in the meta-date of the plug-in MANIFEST.MF.
Dependence is not determined only at runtime, but a compile time option. During the execution of Eclipse make sure that all required dependencies are available to the dependent module and then only activates it. During the Eclipse compile classpath accordingly modifies the dependent plug-in.
Extension
One of the most common and the dependencies used in Eclipse is called "extension points" (extension points). Point is used to extend (extension) of the functional host with many other plugins without direct dependence on him. Extensions and extension points are described in the description file of the plugin plugin.xml.
A good example of extension points is the network of power: an extension point is a plug socket, which can connect to other elements of the grid (lamps, computers, irons) that extend the functionality of the mains. Each device must have a device coordination with the power supply network, otherwise connect it can't.
Continuing the examples, the org.eclipse.ui describes the set of extension points such as editors, "types", "menu". There are other plugin org.eclipse.help.ui that adds your menu item "Help- > Help Contents". To this end, it describes the following extension.
the
<extension point="org.eclipse.ui.actionSets">
<actionSet description="%actionSet.description" id="org.eclipse.help.ui.actions" label="%actionSet.label" visible="true">
<action class="org.eclipse.help.ui.internal.DynamicHelpAction" icon="$nl$/icons/etool16/help.gif" id="org.eclipse.help.ui.dynamicHelp" label="%searchAction.label" style="push" toolbarPath="org.eclipse.ui.workbench.navigate" tooltip="%dynamicHelpAction.tooltip"/>
</actionSet>
</extension>
If there were some strange moments with extension points, we suggest that to understand since the mechanism is essential for the interaction of the plugins.
So read here, here and more in detail with examples SDAs. A list of extension points of the platform are presented SDAs.
Plug-ins, except that can use existing extension points can define a new one. Points are described using *.exsd and the corresponding extension tag-point with reference to the description file.
the
<extension-point id="com.xyz.myplugin.ext"
name="Test Extension Point" schema="schema/myextpoint.exsd"/>
This file will describe the interface extension to the host, namely the required data and/or classes that implement certain interfaces.
Read more about creating your own extension points again at Lars and here.
Useful links
General Eclipse Programming
Eclipse 4 RCP — Tutorial from Lars Vogel
Eclipse Rich Client Platform (2nd Edition)
Top 10 mistakes in Eclipse Plug-in Development
Eclipse Platform
How to Use the Eclipse API
Notes on the Eclipse Plug-in Architecture
Eclipse UI
Inside the Workbench
Eclipse User Interface Guidelines
What then?
If the public wants to know more about Eclipse as a platform for developing applications, I could continue writing articles and shed light on the following technologies
the
-
the
- Eclipse resources the
- Eclipse modeling (EMF/databinding) the
- Eclipse UI (SWT/jface/GEF/GMF/graphiti) the
- Eclipse RCP deployment (maven/tycho)
However, first and foremost, I would like to know what interesting You might delve into the theory — development tools, their concepts, features, or conduct a series of tutorials, which will create a Eclipse plugin, and in parallel let us consider the theoretical aspects of development (idea, what the plugin You are missing in Eclipse are welcome).
Комментарии
Отправить комментарий