Eclipse Foundation изнутри

В статье приведен обзор процесса разработки программного обеспечения с открытым исходным кодом, осуществляемый в рамках организации Eclipse Foundation. С некоторых пор Суровый является коммитером проекта Eclipse Communication Framework, знает процесс изнутри, поэтому может рассказать не только о формальной стороне дела, но и поделиться личными впечатлениями.

Eclipse RCP: Целевые платформы Eclipse (Eclipse Target Platforms)

Начиная с Eclipse 3.3 существует удобная возможность управления бандлами, доступными при разработке плагинов/RCP-приложений с помощью Eclipse PDE. Речь идет о таком понятии, как "целевая платформа" (Eclipse Target Platform) - списке бандлов и параметров, которые будут доступны при компиляции, отладке и тестировании плагинов из рабочего пространства (Eclipse Workspace).

Зачем создавать собственные целевые платформы

По-умолчанию в качестве целевой платформы используется содержимое каталога plugins запущенного экземпляра Eclipse. Обычно в такой целевой платформе содержатся сотни бандлов (в моем Eclipse for RCP and RAP Developers их 467), что как правило очень много и вовсе не нужно для компиляции/отладки/тестирования RCP/RAP-приложения или плагина. Зачем тратить время (особенно при разработке, когда перезапускать приложение приходится довольно часто) на ожидание старта сотен бандлов, если их нужно от силы 20-30?

Взаимодействие c OSGi - Проблемы загрузки классов

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

Взаимодействие с OSGi - Уровни взаимодействия с OSGi

Известный OSGi-евангелист Neil Bartlett начал интересную серию статей о разработке библиотек, способных корректно работать в среде OSGi.

В принципе, многие библиотеки могут работать в OSGi среде, даже если они не предоставляют OSGi-дескриптора (т.е. файла MANIFEST.MF, содержащего поля Bundle-SymbolicName и т.д.), если только они не используют паттерны, создающие проблемы, такие как сканирование ClassPath и вызовы Class.forName(). Данные библиотеки Neil обозначает термином compliant. Другие фреймворки могут более глубоко интегрироваться с OSGi, например использовать сервисы, настраиваться через Config Admin и т.д.

Чтобы сделать диалог между авторами библиотек и OSGi-сообществом более продуктивным Neil предлагает договориться о терминах и ввести следующую шкалу уровней взаимодействия между библиотекой и OSGi.

Сервлеты и OSGi: разворачиваем бандлы на GlassFish v3

В ноябре 2008-го года тогда еще живая SUN Microsystems выпустила новую экспериментальную версию сервера приложений с открытым исходным кодом - GlassFish v3 Prelude. С тех пор вышло несколько стабильных версий данного сервера, последней из которых на сегодняшний день является 3.0.1. Отличительными чертами GlassFish v3 являются модульность и расширяемость, обеспечиваемые использованием технологии OSGi (в реализации Apache Felix). Соответственно, с одной стороны GlassFish v3 предоставляет сервлет-контейнер (как часть спецификации JavaEE 6.0), а с другой - OSGi-фреймворк (Apache Felix или Eclipse Equinox), что позволяет добавлять свои бандлы, в которых можно регистрировать сервлеты.

Подробно вопрос регистрации сервлетов с помощью сервиса HttpService рассматривался в предыдущих статьях серии, поэтому сейчас мы сконцентрируемся только на вопросах развертывания бандлов, содержащих сервлеты, на GlassFish v3.

Запускаем GlassFish v3 на OSGi-фреймворке Equinox

Введение

Одним из преимуществ сервера приложений GlassFish v3 является модульность, которая обеспечивается за счет использования технологии OSGi. По-умолчанию, в качестве OSGi-фреймворка для GlassFish используется Apache Felix, однако имеется возможность запускать данный сервер приложений и поверх другого популярного OSGi-фреймворка с открытым исходным кодом - Eclipse Equinox. Напомню, что на базе Eclipse Equinox построена широкоиспользуемая Java-разработчиками IDE Eclipse, да и вообще вся платформа Eclipse RCP/RAP.

Внимание! Из-за различий в лицензиях GlassFish и Eclipse Equinox сам фреймворк Equinox не поставляется вместе с сервером приложений. Нужно или скачать последнюю версию данного фреймворка или скопировать Jar-файл org.eclipse.osgi_3.x.x.vxxx.jar из имеющейся у вас поставки Eclipse в каталог $GlassFish_HOME/osgi/equinox.

Существует два способа заставить GlassFish запускаться на Equinox: использование переменной окружения GlassFish_Platform и использование опции JVM -DGlassFish_Platform. Рассмотрим эти способы подробнее.

Настраиваем взаимодействие Eclipse - GlassFish v3

Сервер приложений GlassFish является Reference Implementation спецификации JavaEE 6 (так же известной под названием JSR-316), поэтому знакомство с ним будет полезно любому разработчику, планирующему использовать как весь стек JavaEE, так и некоторые его компоненты.

Интегрированная среда разработки Eclipse позволяет упростить взаимодействие с сервером приложений, в частности - автоматизировать создание специфичной для него структуры проекта, облегчить запуск/останов сервера и разворачивание на нем разрабатываемого приложения. Так же очень полезной функцией IDE является обеспечение горячего разворачивания приложения - возможности заменять классы и статический контент "на лету", т.е. непосредственно после компиляции, не прибегая каждый раз к сборке архивов модулей (war, ear, rar, jar) и переустановке приложения целиком. Данная возможность существенно ускоряет разработку и отладку приложения.