Библиотека сайта rus-linux.net
Фреймворк Jitsi
Глава 10 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: "Jitsi", глава 10 из 1 тома книги "The Architecture of Open Source Applications"
Автор: Emil Ivov
Перевод: Н.Ромоданов
10.3. Собираем и запускаем сборку
Теперь, когда мы знаем, как в сборке писать код, наступил момент поговорить о формировании пакетов. Когда сборки работают, им надо указать три различные сущности среды OSGi: пакеты Java, которые они делают доступными для других (например, экспортируемые пакеты), пакеты, которые они хотели бы использовать из сборок (т.е. импортируемые пакеты), а также имя их класса BundleActivator. В сборках это делается при помощи манифеста JAR-файла, который используется при установке сборки.
Для сервиса ConfigurationService
, который мы определили выше, файл манифеста может выглядеть следующим образом:
Bundle-Activator: net.java.sip.communicator.impl.configuration.ConfigActivator Bundle-Name: Configuration Service Implementation Bundle-Description: A bundle that offers configuration utilities Bundle-Vendor: jitsi.org Bundle-Version: 0.0.1 System-Bundle: yes Import-Package: org.osgi.framework, Export-Package: net.java.sip.communicator.service.configuration
После создания манифеста файла JAR, мы готовы создать саму сборку. В Jitsi мы используем Apache Ant, с помощью которого выполняются все задачи, необходимые для создания сборки. Для того, чтобы добавить сборку в процедуру создания Jitsi, вам нужно отредактировать файл build.xml в корневом каталоге проекта. JAR-файлы сборки создаются в конце файла build.xml там, где указываются задачи (цели) bundle-xxx
. Для того, чтобы собрать наш конфигурационный сервис, нам понадобится следующее:
<target name="bundle-configuration"> <jar destfile="${bundles.dest}/configuration.jar" manifest= "${src}/net/java/sip/communicator/impl/configuration/conf.manifest.mf" > <zipfileset dir="${dest}/net/java/sip/communicator/service/configuration" prefix="net/java/sip/communicator/service/configuration"/> <zipfileset dir="${dest}/net/java/sip/communicator/impl/configuration" prefix="net/java/sip/communicator/impl/configuration" /> </jar> </target>
Как вы можете видеть, задача в Ant просто создает JAR-файл используя для этого наш конфигурационный манифест и добавляет к нему пакеты configuration из иерархий service
и impl
. Теперь единственное, что нам нужно сделать, это чтобы Felix их загрузил.
Мы уже упоминали, что Jitsi является простым набором сборок OSGi.
Когда пользователь запускает приложение, он, на самом деле, запускает Felix со списком сборок, которые необходимо загрузить. Вы можете найти этот список в нашем каталоге lib
, внутри файла с именем felix.client.run.properties
. Felix запускает сборки в том порядке, который определяется уровнями запуска: гарантируется, что сборки некоторого конкретного уровня будут запущены перед тем, как начнется загрузка следующего уровня. Хотя на примере кода, приведенного выше, это и не видно, настройки нашего конфигурационного сервиса сохраняются в файлах, поэтому нужно использовать наш файл FileAccessService, находящийся внутри файла fileaccess.jar
. Так что мы проверяем, что ConfigurationService запускается после FileAccessService:
⋮ ⋮ ⋮ felix.auto.start.30= \ reference:file:sc-bundles/fileaccess.jar felix.auto.start.40= \ reference:file:sc-bundles/configuration.jar \ reference:file:sc-bundles/jmdnslib.jar \ reference:file:sc-bundles/provdisc.jar \ ⋮ ⋮ ⋮
Если вы посмотрите на файл felix.client.run.properties
, вы увидите в начале список следующих пакетов:
org.osgi.framework.system.packages.extra= \ apple.awt; \ com.apple.cocoa.application; \ com.apple.cocoa.foundation; \ com.apple.eawt; \ ⋮ ⋮ ⋮
В этом списке Felix-у указывается, какие пакеты, указываемые в системном пути classpath, должны быть доступными для сборок. Это означает, что пакеты, которые есть в этом списке, могут импортироваться сборками (т.е. могут быть добавлены в их заголовок манифеста Import-Package) без какого-либо явного указания на экспорт в любых других сборках. В списке, в основном, указываются пакеты, которые относятся к частям JRE, связанными с определенными особенностями ОС, и разработчикам Jitsi редко требуется добавлять туда новые пакеты; в большинстве случаев пакеты делаются доступными сразу целыми сборками.
Продолжение статьи: 10.4. Сервис провайдера протоколов.