Разработка ста и одного плагина: Часть 1. Основы

Учимся основам разработки плагинов Eclipse.

Эта статья поможет вам научиться основам разработки плагинов и даст некоторые полезные практические рекомендации.

Крис Анищик, программист, IBM

Крис Анищик (Chris Aniszczyk) — коммиттер Eclipse, сотрудник IBM Lotus, занимающийся разработками в рамках инициативы OSGi. В настоящее время основные усилия Криса направлены на совершенствование среды программирования плагинов Eclipse (Plug-in Development Environment, PDE), а также на пропаганду Eclipse среди сотрудников IBM Lotus. Крис — пламенный энтузиаст продуктов с открытым исходным кодом, активный популяризатор open source. Он пропагандирует Eclipse в своем блоге и удостоен чести представлять коммиттеров Eclipse в совете директоров Eclipse Foundation. Крис всегда готов поговорить об open source и Eclipse за стаканчиком чего-нибудь прохладительного.



14.10.2009

Эта серия статей "Разработка ста и одного плагина" посвящена разработке плагинов. Но прежде чем начать, нужно убедиться, что у нас есть подходящая для этого среда. Первый шаг – загрузить из Eclipse.org дистрибутив Eclipse со средой разработки плагинов (Plug-in Development Environment - PDE). Я рекомендую загрузить последнюю версию Eclipse Classic. В этой серии статей мы будем использовать версию Eclipse V3.4 (M5). (О том, где найти Eclipse и дополнительную информацию, см. в разделе Ресурсы.)

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

Рисунок 1. Блок-схема процесса разработки плагина
Блок-схема процесса разработки плагина

Что значит OSGi?

В версии 3.0 Eclipse сделал большой скачок, выбрав OSGi взамен хрупкой технологии плагинов Eclipse, присутствовавшей в более ранних версиях. Технологией OSGi ведает независимая, некоммерческая организация OSGi Alliance. Она выполняет те же функции, что и Eclipse Foundation. OSGi Alliance отвечает за выпуск спецификаций технологии OSGi. Вкратце, технология OSGi обеспечивает сервис-ориентированную платформу на базе плагинов для разработки приложений. Одной из самых популярных реализаций является Equinox, который представляет собой Eclipse-реализацию спецификации. (См. раздел Ресурсы.)

Прежде чем углубиться в детали создания плагина, давайте обсудим, что же это такое. С технической точки зрения плагин – это a Java™ Archive (JAR), то есть самодостаточный и самоопределяемый модуль. Самодостаточный он потому, что содержит код и ресурсы, необходимые плагину для работы. А самоопределяемый потому, что содержит информацию, которая указывает, что это такое, что ему требуется от внешнего мира и что он дает внешнему миру. В плагине обычно присутствует пара файлов дескрипторов: MANIFEST.MF и plugin.xml.

Начнем с создания

Первая часть процесса разработки плагина включает создание проекта плагина. В Eclipse это легко делается выбором варианта меню New >Project.... В появившемся мастере выберите в качестве типа создаваемого проекта Plug-in Project.

Рисунок 2. Мастер создания нового проекта плагина
Мастер создания нового проекта плагина

Как и в любом другом проекте Eclipse, мастер попросит выбрать имя проекта. Я предлагаю helloworld. Есть также возможность выбрать целевую платформу. В данном случае это просто целевая версия Eclipse или среда OSGi, такая как Equinox. Для простоты выберем версию Eclipse 3.3. Следующая страница мастера New Plug-in Project посвящена содержанию плагина.

Рисунок 3. Содержание плагина
Содержание плагина

На этой странице нужно заполнить форму, чтобы сделать наш плагин совместимым с Eclipse. Идентификатор плагина – это поле, содержащее уникальный идентификатор вашего плагина. Никакой другой плагин не должен иметь такой же идентификатор. Версия плагина состоит из четырех частей (трех целых чисел и строки) с именами соответственно major.minor.service.qualifier (о версиях плагинов см. в разделе Ресурсы). Имя плагина – это просто читабельное имя. Поле автора плагина должно быть читабельной строкой с именем автора. Поле execution environment (EE) означает, на какой минимальной версии JRE способен работать ваш пакет (см. раздел Ресурсы).

Мастер предоставляет возможность сгенерировать активатор плагина. Это просто класс, который управляет жизненным циклом плагина (его можно представить как метод пуска-останова). Обычно активатор отвечает за установку и правильное расположение ресурсов, когда плагин больше не используется. В данном случае нам нужен активатор, плагин, который влияет на пользовательский интерфейс, и мы создаем приложение Rich Client Platform (RCP) (см. Ресурсы).

Последний шаг процесса создания плагина состоит в выборе шаблона (см. рисунок 4) для нового плагина. Те, у кого больше опыта по созданию плагинов, обычно пропускают этот шаг, но начинающим нужно с чего-то начать. Eclipse SDK предлагает много шаблонов для этого. Выберем шаблон Hello World с приложением просмотра.

Рисунок 4. Шаблоны плагинов
Шаблоны плагинов

Модификация

Внутри файла MANIFEST.MF

Если вас интересуют различные заголовки, доступные в файле MANIFEST.MF, прочтите спецификации OSGi от OSGi Alliance (см. Ресурсы).

По завершении предыдущего шага в рабочем пространстве появится новый плагин. Теперь у нас есть редактор (см. рисунок 5), который помогает работать с новым плагином. Первая страница редактора, Overview, содержит модифицируемую информацию идентификатора плагина с разделами описаний разных элементов, которые можно редактировать в нашем плагине. Например, поля идентификатора (ID) и версии, которые мы уже определили при помощи шаблона, как показано на рисунке 4.

Рисунок 5. Редактор плагина (страница Overview)
Редактор плагина (страница Overview)

Расширения и точки расширения

Изобилие точек расширения

В SDK Eclipse V3.3 свыше 200 точек расширения. Список расширяемых элементов (то есть точек расширения) SDK приведен в документе Eclipse Foundation под названием "Platform Extension Points" (см. Ресурсы).

На следующем шаге мы добавим расширение. Однако прежде чем вдаваться в детали, нужно усвоить два важных понятия, относящихся к разработке расширяемых плагинов Eclipse: расширения и о точки расширения. Для наглядности расширение (extension) можно сравнить с вилкой, а точку расширения (extension point) — с розеткой. Например, в Eclipse есть точка расширения (розетка) org.eclipse.ui.editors, которая позволяет подключать свой собственный редактор (вилка).

Мы создадим новое расширение, которое будет присутствовать на инструментальной панели Eclipse. Для этого воспользуемся шаблоном (как при создании плагина) для точки расширения org.eclipse.ui.actionSets. На странице Overview редактора выберите ссылку Extensions в разделе Extension/Extension Point Content. Нажмите Add... и выберите шаблон org.eclipse.ui.actionSets (см. рисунок 6) со всеми параметрами по умолчанию.

Рисунок 6. Шаблоны расширений
Шаблоны расширений

Страница Runtime

Важная особенность нашего плагина – его самоопределяемость. В частности, наш плагин должен определять то, что он предлагает миру. В контексте Eclipse это называется экспортируемыми пакетами. Нужно решить, какие пакеты мы будем экспортировать, чтобы другие плагины могли заглянуть в эти пакеты и понять, что они зависят от нашего плагина. Можно также пометить экспортируемые пакеты как внутренние, которые указывают разработчикам, что мы не рассматриваем данный пакет как API. Чтобы определить экспортируемые пакеты, воспользуемся страницей Runtime в редакторе декларации.

Рисунок 7. Страница Runtime
Страница Runtime

Зависимости

Обилие плагинов

В экосистеме Eclipse существует такая масса плагинов, что легко заблудиться. Я рекомендую при поиске плагинов начать с двух сайтов: списка проекта Eclipse Foundation и Eclipse Plug-in Central (EPIC) (см. Ресурсы).

В предыдущем разделе мы описали, что должен делать плагин, чтобы представить миру свою функциональность. Вообразите, что вы – другой плагин и хотите воспользоваться этой функциональностью. Как выразить заинтересованность в этом? В контексте Eclipse это называется зависимостями. В простейшем случае плагины могут зависеть от других плагинов. Например, если вы хотите создать в Eclipse свой собственный редактор, вы будете зависеть от плагина org.eclipse.ui.editors. Для определения зависимостей используется страница Dependencies редактора плагинов.

Рисунок 8. Страница Dependencies
Страница Dependencies

Заметим, что кроме зависимостей от отдельных плагинов можно зависеть от пакетов, экспортируемых из плагинов (см. раздел «Импортируемые пакеты» на следующей странице). Это более сложная тема, и это полезно, когда вы не хотите связывать свой плагин с определенной реализацией. Например, представьте себе зависимость от пакета com.company.xml.parser, который вырабатывается XML-парсером. Допустим, есть два плагина, таких как com.company.xml.parser.mobile и com.company.xml.parser.desktop, которые созданы двумя разными реализациями одного и того же XML-парсера, но для разных сред.

Редакторы исходного кода

Страницы Runtime и Dependencies – это просто визуальные представления того, что описано главным образом в файле MANIFEST.MF. Для продвинутых пользователей, желающих редактировать исходный код этого файла вручную, PDE предлагает редактор исходного кода с завершением кода для различных заголовков из определения декларации плагина.

Рисунок 9. Редактирование исходного кода
Source editing

Тестирование и отладка

На следующем шаге нашего путешествия по плагинам мы займемся тестированием и отладкой. Чтобы можно было проверить плагин, в Eclipse и PDE имеется понятие самохостинга. Это просто означает возможность запустить новый экземпляр Eclipse с плагинами, над которыми мы работаем в своем рабочем пространстве, без необходимости физически экспортировать или развертывать какие-либо плагины. Чтобы запустить новый экземпляр Eclipse нужно вызвать другую среду исполнения через раздел Testing страницы Overview (ссылка Launch an Eclipse application на странице Overview). Через несколько секунд появится новая рабочая среда с примером вашего плагина в действии на панели инструментов.

Рисунок 10. Самохостинг в Eclipse
Self-hosting in Eclipse

Разработка плагина в процессе тестирования

Если вы хотите начать с тестов еще до начала реальной разработки своего плагина, можно создать проект плагина, содержащий только тесты. Существует специальная конфигурация запуска Plug-in JUnit Test для исполнения тестов, содержащихся внутри плагинов.

Чтобы запустить свой самохостируемый плагин в режиме отладки, просто кликните на ссылке Launch an Eclipse application in debug mode в разделе Testing страницы Overview. Чтобы отладить свой плагин, нужно установить соответствующие точки прерывания. Тем, кто еще не знаком с процессом отладки в Eclipse, я рекомендую для начала прочесть статью "Debugging with the Eclipse Platform" (отладка при помощи платформы Eclipse ) на developerWorks (см. Ресурсы).

Чтобы установить более детальные опции для запуска или отладки плагина, перейдите в диалог Launch Configurations, который можно вызвать при помощи опции меню Run > Run Configurations.... Подходящий тип конфигурации запуска для нашего плагина называется "Eclipse Application", так как мы запускаем приложение Eclipse (см. рисунок 11). Внутри конфигурации запуска можно установить аргументы и управлять выбором JRE для запуска приложения.

Рисунок 11. Диалог конфигураций запуска
Диалог конфигураций запуска

Экспорт строк

Обычным шагом при разработке плагинов является интернационализация. Если вы дошли до того, что ваш плагин полезен и будет тестироваться многими другими, вас будут просить сделать так, чтобы этот плагин мог работать на чужом языке. К счастью, работа, необходимая для экспортирования соответствующих строк плагина, минимальна. В PDE есть мастер, который можно вызвать, щелкнув правой кнопкой на странице Overview своего плагина и выбрав из меню Externalize Strings.... Появившийся мастер отобразит все строки, подлежащие экспорту.

Рисунок 12. Мастер экспорта строк
Мастер экспорта строк

На самом деле он просто генерирует файл plugin.properties (который содержит экспортированные строки) для вашего плагина и добавляет заголовок Bundle-Localization к файлу MANIFEST.MF. Заголовок Bundle-Localization позволяет определить имя и возможное положение экспортированных строк. В данном случае Bundle-Localization это "plugin," что означает, что строки для разных языков будут находиться в таких файлах, как plugin.properties (см. рисунок 13) plugin_fr.properties или plugin_de.properties. Все, что стоит после знака подчеркивания в имени файла, означает язык.

Рисунок 13. Файл plugin.properties
The plugin.properties file

Вот и все! Этого достаточно, чтобы начать интернационализацию нашего плагина. За дополнительной информацией я рекомендую обращаться к устаревшим, но все еще актуальным статьям из уголка Eclipse: "How to Internationalize your Eclipse Plug-In" (как интернационализировать плагин Eclipse) и "How to Test Your Internationalized Eclipse Plug-In" (как проверить интернационализированный плагин Eclipse (см. Ресурсы).


Организация деклараций

На следующем шаге организуем свои файлы деклараций (то есть MANIFEST.MF и plugin.xml) с учетом некоторых рекомендаций. В PDE есть удобный мастер, который можно вызвать через раздел Exporting страницы Overview. После запуска мастера (см. рисунок 14) вы увидите ряд параметров, которые можно настраивать. По умолчанию все очень разумно, но есть некоторые полезные параметры, такие как проверка отсутствия лишних ключей в файле plugin.properties.

Рисунок 14. Мастер организации деклараций
Мастер организации деклараций

Заключение

Общей задачей этой статьи было дать представление об основах разработки плагинов с некоторыми практическими рекомендациями. Мы достигли этого, создав пример плагина и пройдя типичный путь в ходе его разработки. Усвоив этот путь, вы значительно упростите себе разработку плагинов даже соблюдением таких процедур, как организация деклараций. Во второй части мы сосредоточимся на использовании инструментов для разработки rich-client приложений и завершим оставшиеся этапы разработки плагина, представленные на рисунке 1.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=435633
ArticleTitle=Разработка ста и одного плагина: Часть 1. Основы
publish-date=10142009