Eclipse RCP Cookbook Part I
In this article I will tell you what the Eclipse Rich Client Platform is, how it works and what it is with. Please pay attention if you are looking for a tutorial on how to create your own RCP, then you are here , I want to tell you how it works from the inside.
It’s almost impossible to look at the entire Eclipse RCP with its long history in one post, so for a start I would like to highlight the basic platform concepts such as the workbench , plugins, dependencies between them, and the runtime.
In the text I will indicate links to useful literature, in particular, to articles
Lars Vogella , he is a recognized speaker in the world of Eclipse technology, and has repeatedly won awards from the Eclipse community.
Eclipse is an extensible platform for creating an IDE. The platform is expanded with plug-ins, each of which can complement Eclipse behavior. For example, adding new editors, menu items, etc.
')
The workbench is the root element of the graphical representation of the Eclipse platform. It may contain one or several windows ( workbench window ), which provide the user with some model. Most often these are resources stored in the workspace . You can open a new window using Window → New Window.
Each window contains a collection of pages ( workbench page ) and a link to the active page, only one page can be active in one window.
Editors ( editors ) and views ( views ) are stored in the page with the help of appropriate managers ( ViewFactory, EditorManager ). Editors and views have a common interface - IWorkbenchPart , then the working part. The workspace does not store references to editors and views, but uses intermediate objects, EditorReference and ViewReference . This allows you to load plugins using lazy initialization . For example, in the following screenshot, plug-ins that define the Hierarchy, Javadoc, and Declaration views may not yet be loaded, as they are not used yet.
Views and editors are very similar to each other, they are part of the page together, have the same mechanism for creating menus and buttons, both of them can display the contents of several files, but there are still conceptual differences between them. Multiple instances of the editor can be created on the same page, unlike views. Editors can display the change status of the file ( dirty ), indicating that there are unsaved changes that can be lost if you close the editor without saving.
The page also contains many perspectives . Perspective is a page template containing a collection of parts, their relative position on the page, keyboard shortcuts for commands, menu visibility, and more. You can customize the perspective using the Window → Customize Perspective command.
Information about user preferences is stored in the [workspace /. Metadata / .plugins / org.eclipse.ui.workbench / directory. Using these files, you can use your perspective settings in various work areas. However, it is still better to use the option of copying settings when switching workspaces.
We read about the workspace here and in more detail here .
A plugin is a component that provides a specific service within the context of a workspace. Examples of plugins are org.eclipse.debug.core , which allows a developer to debug their programs, and org.eclipse.debug.ui , which contains a graphical representation for the first.
The description of the plugin occurs in a special XML file - plugin.xml, which is located in the plugin folder. This file describes how the plugin extends the Eclipse platform (describes editors, views, context menus), how it does it will be described in the "Dependencies" section. The implementation code of the plug-in will be loaded only when the plug-in starts, again delayed initialization. Thus, Eclipse can display plug-in extensions without directly loading it.
An example plugin.xml is presented in the article “What is the plug-in manifest file (plugin.xml)?”
The Eclipse runtime environment provides the functionality responsible for controlling the plug-in's life cycle. The plugin will be loaded only when necessary, and similarly disabled. At the same time, an instance of the instance will be created inside the running eclipse and the interaction class is considered to be the plugin class ( org.eclipse.core.runtime.Plugin ), which is also called the activator. The main function of the activator is to perform additional actions during the start of the plug-in (initialization of images, caching of certain static resources, etc.). If there is no need to perform additional actions, then you can omit the activator and the standard one will be used. Read more about the activator here . The Eclipse runtime environment implements the OSGi specification.
OSGi (Open Services Gateway Initiative) is a specification that allows you to divide a complex system into modules ( bundles ) and remotely install, update, or delete these modules without rebooting the system. Each module has a set of dependencies on other modules and a strictly defined API for interacting with other modules.
Technically, a module is a .jar file that contains additional meta information that is stored in the module META-INF / MANIFEST.MF, this file is part of the jar file specification. A runtime environment other than OSGi will ignore these files.
Also, OSGi describes such components as the bundle, service, life-cycle, services registry, and so on. The OSGi architecture looks like this:
In addition to Eclipse, OSGi has several other implementations, such as Apache Felix , Knopflerfish , Concierge OSGi, and others. Read more about OSGi on the official website , on the wiki and at Lars .
The implementation of OSGi in Eclipse is the philosophical name Equinox . Thus, the plugin is an OSGi module, and its meta information is as follows.
Equinox is responsible for managing dependencies between modules at run time. It reads the MANIFEST.MF module during installation and makes sure that all dependent modules are already loaded and then activates the requested module. If dependencies are not encountered, the module will not load. If a module tries to access a class without a dependency on it, a ClassNotFoundException will be thrown.
OSGi is available for activation of plug-ins, which are located in a separate plugin folder eclipse_install_dir / plugins .
This role is performed by dependent and required plugins. The classic direct dependency is described in the meta-date of the MANIFEST.MF plugin.
Dependency is determined not only at runtime, but also at compile time. At runtime, Eclipse makes sure that all the necessary dependencies are available for the dependent module and then only activates it. During compilation, Eclipse modifies the classpath of the dependent plug-in accordingly.
One of the most common and used dependencies in Eclipse is called extension points . The point is used to extend the ( extension ) functionality of the host with a variety of other plug-ins without a direct relationship to it. Extensions and extension points are described in the plugin description file plugin.xml.
The plug-in defining the extension point allows other plug-ins to add functionality based on the description of the extension. The extension can be both code and data.
A good example of expansion points is the power supply network: in it, the expansion point is a socket into which other elements of the power supply network (lamps, computers, irons) can be connected, which extend the functionality of the power supply network. In addition, each device must have a device matching with the power supply network, otherwise it will not be able to connect.
Continuing the examples, the org.eclipse.ui module describes a number of extension points, such as “editors”, “views”, “menus”. At the same time there is another plugin org.eclipse.help.ui , which adds its own menu item “Help-> Help Contents”. To do this, it describes the following extension
If there are some obscure moments left with the points of expansion, then I advise you to sort it out, since the mechanism is essential for the interaction of plug-ins.
So read here , here and in more detail with examples here . A list of platform expansion points is presented here .
Plug-ins, in addition to using existing extension points, can define new ones. The points are described using * .exsd and the corresponding extension-point tag with reference to the description file.
This file will describe the interface interaction extensions with the host, namely the required data and / or classes that implement certain interfaces.
We read in more detail about creating your own extension points again at Lars and here .
General Eclipse Programming
Eclipse 4 RCP - Tutorial by 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 learn more about Eclipse as an application development platform, then I could continue writing articles and shed light on the following technologies.
However, first of all, I would like to know what interests you, perhaps, go deeper into the theory - development tools, their concepts, features, or conduct a series of tutorials in which we will create an Eclipse plug-in, and in parallel consider the theoretical aspects of development (ideas You lack plug-in in Eclipse, only welcome).
Introduction
It’s almost impossible to look at the entire Eclipse RCP with its long history in one post, so for a start I would like to highlight the basic platform concepts such as the workbench , plugins, dependencies between them, and the runtime.
In the text I will indicate links to useful literature, in particular, to articles
Lars Vogella , he is a recognized speaker in the world of Eclipse technology, and has repeatedly won awards from the Eclipse community.
Eclipse
Eclipse is an extensible platform for creating an IDE. The platform is expanded with plug-ins, each of which can complement Eclipse behavior. For example, adding new editors, menu items, etc.
Workspace
')
The workbench is the root element of the graphical representation of the Eclipse platform. It may contain one or several windows ( workbench window ), which provide the user with some model. Most often these are resources stored in the workspace . You can open a new window using Window → New Window.
Each window contains a collection of pages ( workbench page ) and a link to the active page, only one page can be active in one window.
Editors ( editors ) and views ( views ) are stored in the page with the help of appropriate managers ( ViewFactory, EditorManager ). Editors and views have a common interface - IWorkbenchPart , then the working part. The workspace does not store references to editors and views, but uses intermediate objects, EditorReference and ViewReference . This allows you to load plugins using lazy initialization . For example, in the following screenshot, plug-ins that define the Hierarchy, Javadoc, and Declaration views may not yet be loaded, as they are not used yet.
Views and editors are very similar to each other, they are part of the page together, have the same mechanism for creating menus and buttons, both of them can display the contents of several files, but there are still conceptual differences between them. Multiple instances of the editor can be created on the same page, unlike views. Editors can display the change status of the file ( dirty ), indicating that there are unsaved changes that can be lost if you close the editor without saving.
The page also contains many perspectives . Perspective is a page template containing a collection of parts, their relative position on the page, keyboard shortcuts for commands, menu visibility, and more. You can customize the perspective using the Window → Customize Perspective command.
Information about user preferences is stored in the [workspace /. Metadata / .plugins / org.eclipse.ui.workbench / directory. Using these files, you can use your perspective settings in various work areas. However, it is still better to use the option of copying settings when switching workspaces.
We read about the workspace here and in more detail here .
Plugin
A plugin is a component that provides a specific service within the context of a workspace. Examples of plugins are org.eclipse.debug.core , which allows a developer to debug their programs, and org.eclipse.debug.ui , which contains a graphical representation for the first.
The description of the plugin occurs in a special XML file - plugin.xml, which is located in the plugin folder. This file describes how the plugin extends the Eclipse platform (describes editors, views, context menus), how it does it will be described in the "Dependencies" section. The implementation code of the plug-in will be loaded only when the plug-in starts, again delayed initialization. Thus, Eclipse can display plug-in extensions without directly loading it.
An example plugin.xml is presented in the article “What is the plug-in manifest file (plugin.xml)?”
<?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> Medium of execution
The Eclipse runtime environment provides the functionality responsible for controlling the plug-in's life cycle. The plugin will be loaded only when necessary, and similarly disabled. At the same time, an instance of the instance will be created inside the running eclipse and the interaction class is considered to be the plugin class ( org.eclipse.core.runtime.Plugin ), which is also called the activator. The main function of the activator is to perform additional actions during the start of the plug-in (initialization of images, caching of certain static resources, etc.). If there is no need to perform additional actions, then you can omit the activator and the standard one will be used. Read more about the activator here . The Eclipse runtime environment implements the OSGi specification.
OSGi (Open Services Gateway Initiative) is a specification that allows you to divide a complex system into modules ( bundles ) and remotely install, update, or delete these modules without rebooting the system. Each module has a set of dependencies on other modules and a strictly defined API for interacting with other modules.
Technically, a module is a .jar file that contains additional meta information that is stored in the module META-INF / MANIFEST.MF, this file is part of the jar file specification. A runtime environment other than OSGi will ignore these files.
Also, OSGi describes such components as the bundle, service, life-cycle, services registry, and so on. The OSGi architecture looks like this:
In addition to Eclipse, OSGi has several other implementations, such as Apache Felix , Knopflerfish , Concierge OSGi, and others. Read more about OSGi on the official website , on the wiki and at Lars .
Equinox
The implementation of OSGi in Eclipse is the philosophical name Equinox . Thus, the plugin is an OSGi module, and its meta information is as follows.
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 dependencies between modules at run time. It reads the MANIFEST.MF module during installation and makes sure that all dependent modules are already loaded and then activates the requested module. If dependencies are not encountered, the module will not load. If a module tries to access a class without a dependency on it, a ClassNotFoundException will be thrown.
OSGi is available for activation of plug-ins, which are located in a separate plugin folder eclipse_install_dir / plugins .
Dependencies
Direct dependency
This role is performed by dependent and required plugins. The classic direct dependency is described in the meta-date of the MANIFEST.MF plugin.
Dependency is determined not only at runtime, but also at compile time. At runtime, Eclipse makes sure that all the necessary dependencies are available for the dependent module and then only activates it. During compilation, Eclipse modifies the classpath of the dependent plug-in accordingly.
Expansion
One of the most common and used dependencies in Eclipse is called extension points . The point is used to extend the ( extension ) functionality of the host with a variety of other plug-ins without a direct relationship to it. Extensions and extension points are described in the plugin description file plugin.xml.
The plug-in defining the extension point allows other plug-ins to add functionality based on the description of the extension. The extension can be both code and data.
A good example of expansion points is the power supply network: in it, the expansion point is a socket into which other elements of the power supply network (lamps, computers, irons) can be connected, which extend the functionality of the power supply network. In addition, each device must have a device matching with the power supply network, otherwise it will not be able to connect.
Continuing the examples, the org.eclipse.ui module describes a number of extension points, such as “editors”, “views”, “menus”. At the same time there is another plugin org.eclipse.help.ui , which adds its own menu item “Help-> Help Contents”. To do this, it describes the following extension
<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 are some obscure moments left with the points of expansion, then I advise you to sort it out, since the mechanism is essential for the interaction of plug-ins.
So read here , here and in more detail with examples here . A list of platform expansion points is presented here .
Plug-ins, in addition to using existing extension points, can define new ones. The points are described using * .exsd and the corresponding extension-point tag with reference to the description file.
<extension-point id="com.xyz.myplugin.ext" name="Test Extension Point" schema="schema/myextpoint.exsd"/> This file will describe the interface interaction extensions with the host, namely the required data and / or classes that implement certain interfaces.
We read in more detail about creating your own extension points again at Lars and here .
useful links
General Eclipse Programming
Eclipse 4 RCP - Tutorial by 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 learn more about Eclipse as an application development platform, then I could continue writing articles and shed light on the following technologies.
- Eclipse resources
- Eclipse modeling (EMF / databinding)
- Eclipse UI (SWT / jface / GEF / GMF / graphiti)
- Eclipse RCP deployment (maven / tycho)
However, first of all, I would like to know what interests you, perhaps, go deeper into the theory - development tools, their concepts, features, or conduct a series of tutorials in which we will create an Eclipse plug-in, and in parallel consider the theoretical aspects of development (ideas You lack plug-in in Eclipse, only welcome).
Source: https://habr.com/ru/post/174541/
All Articles