Всем доброго времени суток. Начнем. Во время своего обучения этой технологии я столкнулся с проблемой, что на весь интернет есть только один нормальный источник информации по этой теме (Lars Vogel). А в нем все написано профи для профи. Поверхностно, без деталей. Есть и с деталями, но платно. Я хочу добавить подробностей в довольной простой процесс создания своего первого приложения RCP, поэтому буду делать подробные пояснения к каждому шагу. Это статья подойдет новичкам, не имеющим представления о RCP и Eclipse и желающим сделать первые шаги в освоении этой технологии, но знающим, что такое Java, JDK, JRE.
План:
Скачивание и установка Eclipse
Создание rcp-plugin проекта
Файловая структура RCP проекта
Заключение
1. Скачивание и установка Eclipse
Для работы в Eclipse нужна JDK, поэтому если у вас ее нет, нужно установить. Я использую Java SE Oracle JDK 8, вот ссылка. Работу приложения проверял до 15 версии JDK включительно. Скачиваем файл установки Eclipse версии 2021-03 отсюда. Дальше запускаем скачанный файл и выбираем пункт «Eclipse IDE for RCP and RAP Developers».
Ждем, пока Eclipse установится, и запускаем его.
Меняем настройки окружения самого Eclipse:
Верхний правый угол: Open Perspective -> Java. По умолчанию Eclipse открывается в Plug-in Perspective, но в нашем случае нет необходимости использовать вкладки(в терминах Eclipse вкладки называются part) из этой перспективы, поэтому переключаемся на более удобную в данном случае перспективу «Java».
Window -> Show View -> Project Explorer — задаём отображение проектов в виде иерархии (дерева) вместо списка.
2. Создание rcp-plugin проекта
Мы создадим plugin и дополнительными настройками в wizard добавим папки и файлы, нужные для полноценной работы RCP приложения.
File -> New -> Other -> Plug-in Development -> Plug-in Project.
Установите настройки как показано на скриншоте.
Более подробно о них:
Project name — наименование проекта.
Use default location - имеет смысл менять с дефолтного значения, если у вас есть большой проект и вы создаете плагин внутри этого проекта, или вы просто хотите поместить только что созданный плагин в конкретную директорию.
checkbox установлен — создаст проект в текущем workspace. Workspace — каталог на диске, в котором платформа Eclipse и все установленные надстройки хранят настройки, конфигурации и временную информацию. Последующие вызовы Eclipse будут использовать это хранилище для восстановления предыдущего состояния. Как следует из названия, это ваше «рабочее место».
checkbox снят — создаст проект в выбранной папке (поле Location).
Create a Java project - создавать ли Java project.
checkbox установлен — создается Java проект, т.е. создаются 3 папки: для jre (JRE System Library), для зависимостей самого приложения (Plug-in Dependencies) и папка для исходников. Выберите этот пункт, если вы будете писать код в вашем плагине.
checkbox снят- проект Java не будет создан. Подходит, если, например, вы создаёте плагин для документации.
Source folder — наименование папки для исходников. Общепринятое название - src, но вы спокойно можете сменить название без потери функциональности,
Output folder — наименование папки для скомпилированных классов. Общепринятое название — bin, но вы спокойно можете сменить название без потери функциональности.
Target Platform — выбор платформы – Eclipse или OSGi – контролирует параметры генерации кода, а также список доступных шаблонов
OSGi (Open Services Gateway Initiative) представляет собой спецификацию динамической модульной системы и сервисной платформы для Java-приложений, разрабатываемую консорциумом OSGi Alliance. Данная спецификация определяет модель построения приложения из компонентов, состав которых может изменяться во время выполнения приложения. Подробнее можно найти тут, тут и здесь. Шаблон RCP будет недоступен, поэтому в данной статье этот пункт мы не будем выбирать.
Eclipse - реализация базовой спецификации OSGi. Это также среда выполнения, на которой основаны приложения Eclipse. Будет доступен шаблон для RCP плагина.
Working sets — оставляем как есть. У нас один проект в окружении, working sets не нужны.
Жмем «Next»
Установите настройки как показано на скриншоте.
Более подробно о них:
Properties — набор основных свойств plugin.
ID - является обязательным. Рекомендуется, но не обязательно, чтобы идентификатор плагина совпадал с именем проекта плагина.
Version — версия plugin, по дефолту стоит 1.0.0.qualifier. Слово qualifier – это как SNAPSHOT в maven. При сборке сборщик подставит вместо него метку времени сборки. XYZ.qualifier -> XYZ.YYYYmmddhhmm
Name — наименование плагина, является обязательным. По умолчанию wizard подставляет название проекта в поля ID (все строчными символами) и Name (с заглавного символа) плагина. Смена названия не влияет на функциональность.
Vendor — разработчик, название компании, опционально.
Execution Environment — на какой версии java будете запускать приложение.
Generate an Activator...: если checkbox установлен, то создается Java-класс, который управляет жизненным циклом плагина. Это необходимо только в том случае, если вам необходимо выполнить какие-либо действия при запуске или завершении работы плагина.
This plug-in will make contributions to the UI — дословно переводится «Этот плагин будет вносить вклад в пользовательский интерфейс». Будут сгенерированы специальные файлы и папки для работы с UI. В зависимости от выбора в разделе Rich Client Application:
yes — на следующей странице на выбор будут даны несколько шаблонов генерации кода, где создается окружение для корректной работы RCP приложения. А именно: будут созданы файлы Application.e4xmi, *.product и папки для хранения css файлов с одним дефолтным файлом и папка для иконок с 3 иконками. Свойства этих папок сразу будут прописаны в файл build.properties (свойство bin.includes). Обратите на это внимание, так как если в дальнейшем захотите добавить папку для каких-то ресурсов – не забудьте прописать их в файл build.properties, а то в билде все упадет из-за недоступности ресурсов.
no — на выбор будут даны шаблоны различной сложности, без шаблона для RCP плагина.
Enable API analysis — свойство добавляет статический анализ API вашего плагина. Пример использования:
Вы создаете свой плагин, аннотируете его API и публикуете версию 1.
Миллионы людей будут использовать ваш плагин и создавать свой собственный код, который зависит от API вашего плагина.
При создании 2 версии вашего плагина вы объявляете версию 1 как API-Baseline, с которым автоматически сравниваются изменения вашего кода. Любое изменение в API между версией 1 и 2 показывается вам до того, как вы запустите плагин или тесты. Вы выпускаете версию 2 без каких-либо изменений API.
Миллионы людей могут обновить ваш плагин в своем приложении, потому что новый выпуск плагина совместим с предыдущим.
Rich Client Application:
yes - wizard предложит нам на выбор несколько полноценных примеров приложения 3 и 4 версий.
no — wizard предложит нам множество примеров дополнений (contributions) для 3 и 4 версий. Contribution — это дополнение или расширение уже существующего приложения, которое легко подключить и так же легко отключить. Это могут быть отдельные команды, пункты панели инструментов или меню, отдельные парты или даже перспективы.
Тема и цель данной статьи – создать простой пример RCP приложения, поэтому из всех возможных вариантов мы будем рассматривать только шаблон который создает RCP приложение — Eclipse 4 RCP application.
Выбираем пункт «Yes» и жмем «Next»
Окно выбора templates для генерации приложения. Выбираем Eclipse 4 RCP application.
Жмем «Next»
Установите настройки как показано на скриншоте.
Более подробно о них:
Application window title — заголовок окна приложения.
Create sample content — сгенерируются несколько вкладок, главное меню и классы, отвечающие за действия при нажатии на кнопки в главном меню.
Java package name — название пакета, в котором будут лежать исходники. Поскольку есть Naming Conventions для package name, то логично, что при генерации плагина можно было бы заранее указать нужную структуру папок, а не создавать ее потом. В этом поле это можно сделать.
Add life cycle class — будет сгенерирован класс с набором аннотаций, которые срабатывают в разные моменты жизненного цикла приложения (перед открытием, сразу после полной загрузки, перед закрытием и т.д.). Этот класс будет прописан в расширениях со свойством lifeCycleURI.
Нажимаем «Finish»
Eclipse предложит нам перейти на другую perspective для Plug-in development. Нажимаем «No», так как мы не будем использовать дополнительные вкладки этой перспективы.
И вот мы создали первое RCP приложение. Чтобы убедиться, что все работает и запускается, зайдите в файл *.product, лежащий в корневой папке приложения, и нажмите в верхнем правом углу зеленый треугольник launch an Eclipse application. Если вы все сделали правильно, то должно открыться вот такое окно:
3. Файловая структура rcp проекта
Именно такая файловая структура должна получиться, если все сделать как я описывал.
Test — созданный нами plugin.
JRE System Library — системная библиотека JRE, добавляется самим eclipse при создании Java приложения. В ней отображаются .jar файлы той jdk, что вы подключили к приложению в пункте Execution Environment на первой странице настроек.
Plug-in Dependencies — папка для .jar файлов ваших зависимостей. Посмотреть список зависимостей можно в файле MANIFEST.MF на вкладке Dependencies. В папке список будет больше, чем в файле, так как включает и транзитивные зависимости.
src — исходники. Как вы видите, структура папок (com.firstarticle.test) между src и сгенерированными классами именно такая, которую мы указали на последнем шаге создания приложения.
css — папка для конкретных ресурсов (css).
icons — папка для конкретных ресурсов (icons).
META-INF -> MANIFEST.MF. Клик правой кнопкой мыши -> Open with -> Plug-in manifest editor. Открылся пользовательский редактор настроек плагина. Он объединяет в себе три файла из файловой структуры приложения (MANIFEST.MF, build.properties, plugin.xml).
Overview - страница обзора служит двойной цели:
Он содержит два основных раздела, определяющих важные свойства плагина: «General Information» и «Execution Environments».
Он работает как краткий справочник по разработке, тестированию и развертыванию плагинов, предоставляя разделы «Plug-in Content», «Extensions», «Testing» и «Exporting». Эти разделы содержат гиперссылки, при нажатии на которые можно переходить на другие страницы или вызывать команды.
Plug-in Dependencies — показаны зависимости вашего плагина от других плагинов. На этой странице вы должны перечислить все плагины, которые вы используете в своем проекте.
Runtime — показаны все пакеты, которые ваш плагин делает видимыми для других плагинов, а также библиотеки и папки, составляющие путь к классам среды выполнения подключаемого модуля.
Extensions — это центральный механизм, влияющий на поведение платформы. Тут есть один пункт, если его раскрыть, то мы увидим lifeCycleURI — то расширение, что создалось при генерации плагина. Оно позволяет нам следить за жизненным циклом плагина.
Plug-in Extensions points — определяют новые функциональные точки для платформы, к которым могут подключаться другие плагины.
Build — содержит всю информацию, необходимую для сборки, упаковки и экспорта плагина. Хотя он отображается как страница в редакторе манифеста, изменения, внесенные в него, записываются в файл build.properties. Файл build.properties управляет исключительно процессом сборки.
MANIFEST.MF, build.properties, plugin.xml — исходники. В них отображаются все те изменения, что мы вносили в предыдущих вкладках, плюс там есть доп.настройки, не вошедшие в пользовательский редактор и на этапе ознакомления с созданием приложения не используемые нами.
test.product — Клик правой кнопкой мыши -> Open with -> Product Configuration editor - именно этот файл – главный в нашем приложении. Из него мы запускаем приложение, в нем указаны все зависимости на приложение, начиная от плагина, что мы создали и его зависимостей (т.е. файл MANIFEST.MF — это настройки плагина, а файл test.product - настройки приложения), и до огромного количества плагинов, которые нужны для запуска платформы RCP.
Overview — содержит разделы «General Information», «Product Definition», определяющие основные свойства продукта, и разделы «Testing», «Exporting», в которых содержатся ссылки на тестирование и экспорт.
Contents - определяет все зависимости продукта.
Configuration — определяет информацию, которая создает файл конфигурации, необходимый для запуска продукта.
Launching — настраивается собственная программа запуска вашего продукта и аргументы запуска.
Splash - предоставляет возможность настроить экран-заставку вашего продукта.
Branding — придает продукту индивидуальность, настраивая изображения окон, диалоговое окно «О программе» и приветствие.
Customization — можно добавить свой файл свойств запуска продукта и свой css-файл настроек для внешнего вида приложения.
Licensing — на странице лицензирования вы можете добавить URL-адрес и текст лицензии для вашего продукта.
Updates — позволяет настроить обновление приложения из сторонних источников
Source — исходный вид файла test.product.
Application.e4xmi - описывает структуру приложения, может содержать как визуальные элементы (part, perspective, window), так и не визуальные (handler, command, addon). В сгенерированном примере есть и то и другое, можно посмотреть.
4. Заключение
При изучении технологии и дальнейшем ее использовании, я столкнулся с проблемой малого количества информации, ее фрагментарности и конечно же она была крайне устаревшей. И сформировать какое-то общее понимание того как это все работает, а не тупое использование заученных действий, оказалось крайне сложно. Поэтому в этой статье я постарался дать как можно более подробный контекст при создании приложения, для того чтобы вы могли избежать моих трудностей. Всего доброго.