Ця серія статей "Розробка ста і одного плагіна" присвячена розробці плагінів. Але перш ніж почати, потрібно переконатися, що у нас є відповідна для цього середу. Перший крок - завантажити з 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 присвячена змістом плагіна.
Майстер надає можливість згенерувати активатор плагіна. Це просто клас, який управляє життєвим циклом плагіна (його можна представити як метод пуску-зупинки). Зазвичай активатор відповідає за установку і правильне розташування ресурсів, коли плагін більше не використовується. В даному випадку нам потрібен активатор, плагін, який впливає на призначений для користувача інтерфейс, і ми створюємо додаток Rich Client Platform (RCP) (див. Ресурси).
Малюнок 4. Шаблони плагінів
модифікація
Всередині файлу MANIFEST.MF
Якщо вас цікавлять різні заголовки, доступні в файлі MANIFEST.MF, прочитайте специфікації OSGi від OSGi Alliance (див. Ресурси).
Розширення і точки розширення
Достаток точок розширення
У SDK Eclipse V3.3 понад 200 точок розширення. Список розширюваних елементів (тобто точок розширення) SDK наведено в документі Eclipse Foundation під назвою "Platform Extension Points" (див. Ресурси).
Малюнок 6. Шаблони розширень
сторінка Runtime
Малюнок 7. Сторінка Runtime
залежності
Велика кількість плагінів
В екосистемі Eclipse існує така маса плагінів, що легко заблукати. Я рекомендую при пошуку плагінів почати з двох сайтів: списку проекту Eclipse Foundation і Eclipse Plug-in Central (EPIC) (див. Ресурси).
Малюнок 8. Сторінка Dependencies
Зауважимо, що крім залежності від окремих плагінів можна залежати від пакетів, що експортуються з плагінів (див. Розділ «Імпортовані пакети» на наступній сторінці). Це більш складна тема, і це корисно, коли ви не хочете пов'язувати свій плагін з певною реалізацією. Наприклад, уявіть собі залежність від пакета com.company.xml.parser. який виробляється XML-парсер. Припустимо, є два плагіна, таких як com.company.xml.parser.mobile і com.company.xml.parser.desktop. які створені двома різними реалізаціями одного і того ж XML-парсера, але для різних середовищ.
Малюнок 9. Редагування вихідного коду
Тестування та налагодження
Малюнок 10. Самохостінг в 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
організація декларацій
На наступному кроці організуємо свої файли декларацій (тобто MANIFEST.MF і plugin.xml) з урахуванням деяких рекомендацій. У PDE є зручний майстер, який можна викликати через розділ Exporting сторінки Overview. Після запуску майстра (див. Малюнок 14) ви побачите ряд параметрів, які можна налаштовувати. За замовчуванням всі дуже розумно, але є деякі корисні параметри, такі як перевірка відсутності зайвих ключів у файлі plugin.properties.
Малюнок 14. Майстер організації декларацій
висновок
Загальним завданням цієї статті було дати уявлення про основи розробки плагінів з деякими практичними рекомендаціями. Ми досягли цього, створивши приклад плагіна і пройшовши типовий шлях в ході його розробки. Засвоївши цей шлях, ви значно спростите собі розробку плагінів навіть дотриманням таких процедур, як організація декларацій. У другій частині ми зосередимося на використанні інструментів для розробки rich-client додатків і завершимо залишилися етапи розробки плагіна, представлені на малюнку 1.