Desktop. Не популярный, но все еще живой. Eclipse Rich Client Platform (RCP e4)

Всем доброго времени суток. Начнем. Во время своего обучения этой технологии я столкнулся с проблемой, что на весь интернет есть только один нормальный источник информации по этой теме (Lars Vogel). А в нем все написано профи для профи. Поверхностно, без деталей. Есть и с деталями, но платно. Я хочу добавить подробностей в довольной простой процесс создания своего первого приложения RCP, поэтому буду делать подробные пояснения к каждому шагу. Это статья подойдет новичкам, не имеющим представления о RCP и Eclipse и желающим сделать первые шаги в освоении этой технологии, но знающим, что такое Java, JDK, JRE.

План:

1. Скачивание и установка Eclipse

2. Создание rcp-plugin проекта

3. Файловая структура RCP проекта

4. Заключение

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. Заключение

При изучении технологии и дальнейшем ее использовании, я столкнулся с проблемой малого количества информации, ее фрагментарности и конечно же она была крайне устаревшей. И сформировать какое-то общее понимание того как это все работает, а не тупое использование заученных действий, оказалось крайне сложно. Поэтому в этой статье я постарался дать как можно более подробный контекст при создании приложения, для того чтобы вы могли избежать моих трудностей. Всего доброго.