В данной статье я расскажу, что такое Eclipse Rich Client Platform, как она работает и с чем ее есть. Прошу обратить внимание, если вы ищите туториал, как создать свою RCP, то вам сюда, я же хочу рассказать как она работает изнутри.
Рассмотреть всю Eclipse RCP со своей многолетней историей в одном посте практически невозможно, поэтому для начала я хотел бы осветить основные концепции платформы, такие как рабочая область (workbench), плагины, зависимости между ними и среда выполнения.
В тексте я буду указывать ссылки на полезную литературу, в частности, на статьи
Ларса Вогеллы, он является признанным докладчиком в мире Eclipse технологий, и неоднократным обладателем наград сообщества Eclipse.
Eclipse — это расширяемая платформа для создания IDE. Платформа расширяется с помощью плагинов, каждый из которых может дополнять поведение Eclipse. Например, добавляя новые редакторы, пункты меню и т.д.
Рабочая область (workbench) — это корневой элемент графического представления Eclipse платформы. Она может содержать одно или несколько окон (workbench window), которые предоставляют пользователю некоторую модель. Чаще всего это ресурсы, хранящиеся в рабочем пространстве (workspace). Открыть новое окно можно с помощью пункта Window → New Window.
Каждое окно содержит коллекцию страниц (workbench page) и ссылку на активную страницу, только одна страница может быть активна в одном окне.
Редакторы (editors) и виды (views) хранятся в странице с помощью соответствующих менеджеров (ViewFactory, EditorManager). У редакторов и видов есть общий интерфейс — IWorkbenchPart, далее рабочая часть. Рабочая область не хранит ссылки на редакторы и виды, а использует промежуточные объекты EditorReference и ViewReference. Это позволяет загружать плагины, используя отложенную инициализацию (lazy initialization). Например, на следующем скриншоте плагины, в которых определены виды Hierarchy, Javadoc и Declaration, могут быть ещё не загружены, поскольку пока не используются.
Виды и редакторы очень похожи друг на друга, они вместе являются частями страницы, имеют одинаковый механизм для создания меню и кнопок, те и другие могут отображать содержимое нескольких файлов, однако все же между ними есть концептуальные отличия. Несколько экземпляров редактора может быть создано на одной странице, в отличие от видов. Редакторы могут отображать состояние изменения файла (dirty), сообщая о том что есть несохраненные изменения, которые могут быть утеряны, если закрыть редактор без сохранения.
Страница также содержит в себе множество перспектив (perspective). Перспектива — это шаблон страницы, содержащий коллекцию частей, их взаимное расположение на странице, сочетания клавиш для команд, видимость меню и многое другое. Настроить перспективу можно с помощью команды Window → Customize Perspective.
Информация о пользовательских настройках хранится в директории [workspace]/.metadata/.plugins/org.eclipse.ui.workbench/. С помощью этих файлов вы можете использовать свои настройки перспектив в различных рабочих областях. Однако все же лучше использовать опцию копирования настроек при переключении рабочих областей.
Читаем про рабочую область здесь и более подробно здесь.
Плагин — это компонент, который предоставляет определенный сервис внутри контекста рабочей области. Примером плагинов могут быть org.eclipse.debug.core, который позволяет разработчику отлаживать свои программы, и org.eclipse.debug.ui, содержащий графическую представление для первого.
Описание плагина происходит в специальном XML файле — plugin.xml, лежащего в папке плагина. Данный файл описывает каким образом плагин расширяет Eclipse платформу (описывает редакторы, виды, контекстные меню), каким образом он это делает будет описано в разделе «Зависимости». Код имплементации плагина будет загружен только тогда, когда плагин запустится, снова отложенная инициализация. Таким образом Eclipse может отображать расширения плагина без его непосредственной загрузки.
Пример plugin.xml представлен в статье «What is the plug-in manifest file (plugin.xml)?»
Среда выполнения Eclipse предоставляет функциональность отвечающую за контроль жизненного цикла плагина. Плагин будет загружен только тогда, когда это необходимо, и аналогично отключен. При этом внутри запущенной eclipse будет создан экземпляр (instance) плагина и точкой взаимодействия считается класс плагина (org.eclipse.core.runtime.Plugin), его же называют активатором. Основная функция активатора — произвести дополнительные действия во время старта плагина (инициализация изображений, кэширование определенных статических ресурсов и т.д.). Если нет необходимости производить дополнительные действия, то можно не указывать активатор и будет использован стандартный. Более подробно об активаторе читаем здесь. Среда выполнения Eclipse реализует спецификацию OSGi.
OSGi (Open Services Gateway Initiative) — это спецификация, позволяющая разделить сложную систему на модули (bundles) и удалённо устанавливать, обновлять или удалять эти модули без перезагрузки системы. У каждого модуля есть набор зависимостей на другие модули и строго определенное API для взаимодействия с другими модулями.
Технически, модуль — это .jar файл, который содержит дополнительную мета информацию, которая хранится в META-INF/MANIFEST.MF модуля, данный файл является частью спецификации jar файла. Среда выполнения отличная от OSGi будет игнорировать данные файлы.
Также в OSGi описаны такие компоненты, как bundle, service, life-cycle, services registry и так далее. OSGi архитектура выглядит следующим образом:
Кроме Eclipse, OSGi имеет еще несколько других имплементаций, таких как Apache Felix, Knopflerfish, Concierge OSGi и другие. Более подробно об OSGi читаем на официальном сайте, в вики и у Ларса.
Имплементация OSGi в Eclipse носит философское название Equinox. Таким образом плагин является модулем OSGi, и его мета информация выглядит следующим образом.
Equinox отвечает за управление зависимостями между модулями во время выполнения. Он читает MANIFEST.MF модуля во время установки и убеждается что все зависимые модули уже загружены и затем активирует запрашиваемый модуль. Если зависимости не встречаются, модуль не загрузится. Если модуль пытается обратится к классу без зависимости на него, будет выброшен ClassNotFoundException.
OSGi доступны для активации плагины, которые находятся в отдельной папке плагинов eclipse_install_dir/plugins.
Эту роль исполняют зависимый и требуемый плагины. Классическая прямая зависимость описывается в мета-дате плагина MANIFEST.MF.
Зависимость определяется не только во время выполнения, но и во время компилирования. Во время выполнения Eclipse убеждается, что все необходимые зависимости доступны для зависимого модуля и потом только активирует его. Во время компилирования Eclipse соответственно изменяет classpath зависимого плагина.
Одна из самых распространенных и используемых зависимостей в Eclipse имеет название «точки расширения» (extension points). Точки используется для расширения (extension) функционала хоста множеством других плагинов без прямой зависимости на него. Расширения и точки расширения описывается в файле описания плагина plugin.xml.
Плагин, определяющий точку расширения позволяет другим плагинам добавить функциональность, основываясь на описании расширения. Расширение может быть как кодом, так и данными.
Хорошим примером точек расширения является сеть электропитания: в ней точкой расширения является розетка, в которую могут подключаться другие элементы электросети (лампы, компьютеры, утюги), которые расширяют функционал электросети. При этом каждое устройство должно иметь устройство согласование с сетью электропитания, иначе подключиться оно не сможет.
Продолжая примеры, в модуле org.eclipse.ui описано множество точек расширения, таких как «редакторы», «виды», «меню». При этом есть другой плагин org.eclipse.help.ui, который добавляет свой пункт меню «Help->Help Contents». Для этого в нем описано следующее расширение
Если остались какие-то непонятные моменты с точками расширения, то советую разобраться, так как механизм является основным для взаимодействия плагинов.
Так что читаем здесь, здесь и более подробно с примерами здесь. Список точек расширения платформы представлен здесь.
Плагины, кроме того, что могут использовать уже существующие точки расширения, могут определять новые. Точки описываются с помощью *.exsd и соответствующим тегом extension-point со ссылкой на файл описания.
В этом файле будет описан интерфейс взаимодействия расширений с хостом, а именно требуемые данные и/или классы, реализующие определенные интерфейсы.
Читаем более подробно о создании собственных точек расширений снова у Ларса и здесь.
General Eclipse Programming
Eclipse 4 RCP — Tutorial от 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
Если публика захочет узнать дальше об Eclipse, как о платформе для разработки приложений, то я мог бы продолжить написание статей и пролить свет на следующие технологии
Однако, в первую очередь, хотелось бы узнать, что интересно Вам, возможно, углубится в теорию — инструменты разработки, их концепции, особенности, или же провести серию туториалов, в которой создадим Eclipse плагин, и параллельно рассмотрим теоретические аспекты разработки (идеи, какого плагина Вам не хватает в Eclipse, только приветствуются).
Введение
Рассмотреть всю Eclipse RCP со своей многолетней историей в одном посте практически невозможно, поэтому для начала я хотел бы осветить основные концепции платформы, такие как рабочая область (workbench), плагины, зависимости между ними и среда выполнения.
В тексте я буду указывать ссылки на полезную литературу, в частности, на статьи
Ларса Вогеллы, он является признанным докладчиком в мире Eclipse технологий, и неоднократным обладателем наград сообщества Eclipse.
Eclipse
Eclipse — это расширяемая платформа для создания IDE. Платформа расширяется с помощью плагинов, каждый из которых может дополнять поведение Eclipse. Например, добавляя новые редакторы, пункты меню и т.д.
Рабочая область
Рабочая область (workbench) — это корневой элемент графического представления Eclipse платформы. Она может содержать одно или несколько окон (workbench window), которые предоставляют пользователю некоторую модель. Чаще всего это ресурсы, хранящиеся в рабочем пространстве (workspace). Открыть новое окно можно с помощью пункта Window → New Window.
Каждое окно содержит коллекцию страниц (workbench page) и ссылку на активную страницу, только одна страница может быть активна в одном окне.
Редакторы (editors) и виды (views) хранятся в странице с помощью соответствующих менеджеров (ViewFactory, EditorManager). У редакторов и видов есть общий интерфейс — IWorkbenchPart, далее рабочая часть. Рабочая область не хранит ссылки на редакторы и виды, а использует промежуточные объекты EditorReference и ViewReference. Это позволяет загружать плагины, используя отложенную инициализацию (lazy initialization). Например, на следующем скриншоте плагины, в которых определены виды Hierarchy, Javadoc и Declaration, могут быть ещё не загружены, поскольку пока не используются.
Виды и редакторы очень похожи друг на друга, они вместе являются частями страницы, имеют одинаковый механизм для создания меню и кнопок, те и другие могут отображать содержимое нескольких файлов, однако все же между ними есть концептуальные отличия. Несколько экземпляров редактора может быть создано на одной странице, в отличие от видов. Редакторы могут отображать состояние изменения файла (dirty), сообщая о том что есть несохраненные изменения, которые могут быть утеряны, если закрыть редактор без сохранения.
Страница также содержит в себе множество перспектив (perspective). Перспектива — это шаблон страницы, содержащий коллекцию частей, их взаимное расположение на странице, сочетания клавиш для команд, видимость меню и многое другое. Настроить перспективу можно с помощью команды Window → Customize Perspective.
Информация о пользовательских настройках хранится в директории [workspace]/.metadata/.plugins/org.eclipse.ui.workbench/. С помощью этих файлов вы можете использовать свои настройки перспектив в различных рабочих областях. Однако все же лучше использовать опцию копирования настроек при переключении рабочих областей.
Читаем про рабочую область здесь и более подробно здесь.
Плагин
Плагин — это компонент, который предоставляет определенный сервис внутри контекста рабочей области. Примером плагинов могут быть org.eclipse.debug.core, который позволяет разработчику отлаживать свои программы, и org.eclipse.debug.ui, содержащий графическую представление для первого.
Описание плагина происходит в специальном XML файле — plugin.xml, лежащего в папке плагина. Данный файл описывает каким образом плагин расширяет Eclipse платформу (описывает редакторы, виды, контекстные меню), каким образом он это делает будет описано в разделе «Зависимости». Код имплементации плагина будет загружен только тогда, когда плагин запустится, снова отложенная инициализация. Таким образом Eclipse может отображать расширения плагина без его непосредственной загрузки.
Пример plugin.xml представлен в статье «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>
Cреда выполнения
Среда выполнения Eclipse предоставляет функциональность отвечающую за контроль жизненного цикла плагина. Плагин будет загружен только тогда, когда это необходимо, и аналогично отключен. При этом внутри запущенной eclipse будет создан экземпляр (instance) плагина и точкой взаимодействия считается класс плагина (org.eclipse.core.runtime.Plugin), его же называют активатором. Основная функция активатора — произвести дополнительные действия во время старта плагина (инициализация изображений, кэширование определенных статических ресурсов и т.д.). Если нет необходимости производить дополнительные действия, то можно не указывать активатор и будет использован стандартный. Более подробно об активаторе читаем здесь. Среда выполнения Eclipse реализует спецификацию OSGi.
OSGi (Open Services Gateway Initiative) — это спецификация, позволяющая разделить сложную систему на модули (bundles) и удалённо устанавливать, обновлять или удалять эти модули без перезагрузки системы. У каждого модуля есть набор зависимостей на другие модули и строго определенное API для взаимодействия с другими модулями.
Технически, модуль — это .jar файл, который содержит дополнительную мета информацию, которая хранится в META-INF/MANIFEST.MF модуля, данный файл является частью спецификации jar файла. Среда выполнения отличная от OSGi будет игнорировать данные файлы.
Также в OSGi описаны такие компоненты, как bundle, service, life-cycle, services registry и так далее. OSGi архитектура выглядит следующим образом:
Кроме Eclipse, OSGi имеет еще несколько других имплементаций, таких как Apache Felix, Knopflerfish, Concierge OSGi и другие. Более подробно об OSGi читаем на официальном сайте, в вики и у Ларса.
Equinox
Имплементация OSGi в Eclipse носит философское название Equinox. Таким образом плагин является модулем OSGi, и его мета информация выглядит следующим образом.
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 отвечает за управление зависимостями между модулями во время выполнения. Он читает MANIFEST.MF модуля во время установки и убеждается что все зависимые модули уже загружены и затем активирует запрашиваемый модуль. Если зависимости не встречаются, модуль не загрузится. Если модуль пытается обратится к классу без зависимости на него, будет выброшен ClassNotFoundException.
OSGi доступны для активации плагины, которые находятся в отдельной папке плагинов eclipse_install_dir/plugins.
Зависимости
Прямая зависимость
Эту роль исполняют зависимый и требуемый плагины. Классическая прямая зависимость описывается в мета-дате плагина MANIFEST.MF.
Зависимость определяется не только во время выполнения, но и во время компилирования. Во время выполнения Eclipse убеждается, что все необходимые зависимости доступны для зависимого модуля и потом только активирует его. Во время компилирования Eclipse соответственно изменяет classpath зависимого плагина.
Расширение
Одна из самых распространенных и используемых зависимостей в Eclipse имеет название «точки расширения» (extension points). Точки используется для расширения (extension) функционала хоста множеством других плагинов без прямой зависимости на него. Расширения и точки расширения описывается в файле описания плагина plugin.xml.
Плагин, определяющий точку расширения позволяет другим плагинам добавить функциональность, основываясь на описании расширения. Расширение может быть как кодом, так и данными.
Хорошим примером точек расширения является сеть электропитания: в ней точкой расширения является розетка, в которую могут подключаться другие элементы электросети (лампы, компьютеры, утюги), которые расширяют функционал электросети. При этом каждое устройство должно иметь устройство согласование с сетью электропитания, иначе подключиться оно не сможет.
Продолжая примеры, в модуле org.eclipse.ui описано множество точек расширения, таких как «редакторы», «виды», «меню». При этом есть другой плагин org.eclipse.help.ui, который добавляет свой пункт меню «Help->Help Contents». Для этого в нем описано следующее расширение
<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>
Если остались какие-то непонятные моменты с точками расширения, то советую разобраться, так как механизм является основным для взаимодействия плагинов.
Так что читаем здесь, здесь и более подробно с примерами здесь. Список точек расширения платформы представлен здесь.
Плагины, кроме того, что могут использовать уже существующие точки расширения, могут определять новые. Точки описываются с помощью *.exsd и соответствующим тегом extension-point со ссылкой на файл описания.
<extension-point id="com.xyz.myplugin.ext"
name="Test Extension Point" schema="schema/myextpoint.exsd"/>
В этом файле будет описан интерфейс взаимодействия расширений с хостом, а именно требуемые данные и/или классы, реализующие определенные интерфейсы.
Читаем более подробно о создании собственных точек расширений снова у Ларса и здесь.
Полезные ссылки
General Eclipse Programming
Eclipse 4 RCP — Tutorial от 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
Что потом?
Если публика захочет узнать дальше об Eclipse, как о платформе для разработки приложений, то я мог бы продолжить написание статей и пролить свет на следующие технологии
- Eclipse resources
- Eclipse modeling (EMF/databinding)
- Eclipse UI (SWT/jface/GEF/GMF/graphiti)
- Eclipse RCP deployment (maven/tycho)
Однако, в первую очередь, хотелось бы узнать, что интересно Вам, возможно, углубится в теорию — инструменты разработки, их концепции, особенности, или же провести серию туториалов, в которой создадим Eclipse плагин, и параллельно рассмотрим теоретические аспекты разработки (идеи, какого плагина Вам не хватает в Eclipse, только приветствуются).
