Расширения Eclipse и декларативные сервисы - PullRequest
Новая
       19

Расширения Eclipse и декларативные сервисы

4 голосов
/ 27 марта 2009

Я немного запутался в подходе к расширениям / сервисам в архитектуре Eclipse. Разработчику доступны две опции:

  1. Использование расширений Eclipse - http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
  2. Использование декларативных услуг - http://www.eclipse.org/equinox/bundles/

Когда вы будете использовать один над другим и каковы преимущества и недостатки каждого подхода? Кроме того, что является предпочтительным подходом?

Ответы [ 2 ]

4 голосов
/ 27 марта 2009

Есть довольно хорошее сравнение (с 2007 года, я думаю) для EclipseZone: Сравнение Eclipse Extensions и OSGi Services .

Я бы следовал соглашениям вашей целевой платформы. Итак, если вы пишете плагин для Eclipse 3.4, скажем, создайте плагин Eclipse 3.4 (который будет использовать MANIFEST.MF для зависимостей и plugin.xml для расширений / точки расширения - статья, на которую вы ссылаетесь, предназначена для Eclipse 2.x). Вы можете проверить содержимое каталога plugins , чтобы подтвердить это.

2 голосов
/ 27 марта 2009

Проблема с «текущим» подходом (pre3.5M5, как и eclipse3.4) заключается в том, что как расширение плагинов Eclipse, так и OSGI DS (декларативные службы) действительно требуют наличия определенного специфичного для расширения или OSGI-специфичного API в ваш плагин.

Я бы посоветовал вам проверить это хорошее введение в декларативные услуги в этой презентации Powerpoint:
Компонентно-ориентированная разработка в OSGi с декларативными сервисами, Spring Dynamic Modules и Apache iPOJO , от EclipseCON2009.

Вот вкус:

Уровень модуля позволяет минимизировать статические зависимости, а меньшее количество статических зависимостей означает меньшее материал , который должен присутствовать для работы вашего компонента.
Службы позволяют вашему компоненту взаимодействовать с другими компонентами.

Компоненты должны быть реализованы как POJO (простые старые объекты Java) склеены вместе со службами OSGi.

Декларативные услуги (DS) - это спецификация OSGi Compendium, раздел 112.
Он был представлен в версии 4.0 и основан на модели расширителя.

Как и все расширители, DS выполняет задачи от имени других пакетов. Спецификация DS определяет этот расширитель, и он реализуется фреймворками.
Сам комплект расширителей называется Run компонента службы или SCR.

Термины DS и SCR иногда путают:
DS - это спецификация, SCR - фактический пакет, который реализует спецификацию

Существуют значительные улучшения в DS в OSGi R4.2.
Многие из этих изменений поддерживаются в Equinox 3.5M5 +.

SCR («Среда выполнения компонента службы», представляющая собой «пакет расширения», реализующий новую и улучшенную OSGi R4.2 DS - декларативная служба - спецификация):

  • Создает компоненты.
  • Связывает их с сервисами и конфигурацией
  • Управляет жизненным циклом компонента в ответ на приход и уход связанных служб.
  • При желании публикует компоненты как сервисы

У вас еще есть MANIFEST.MF: 

Bundle-SymbolicName : mybundle
Bundle-Version : 1.0.0
Service-Component : OSGI-INF/minimal. xml

Вы будете использовать: 

org.eclipse.equinox.ds <version>.jar
org.eclipse.equinox.util <version>.jar

SCR найдет методы активации / деактивации автоматически.
Мы можем назвать их как-нибудь еще, добавив атрибуты в объявление XML .

До R4.2 имена методов не могли быть изменены, и они должны были принимать параметр типа ComponentContext из DS API. Это сломало изящество компонента.

Таким образом, вместо того, чтобы писать "BundleActivator" (OSGI-специфичный API в вашем компоненте: BAD), вы пишете простой объект POJO: 

public class PollingComponent {
    private static final int DEFAULT_PERIOD = 2000;
    private PollingThread thread ;
    protected void activate ( Map<String , Object> config ) {
        System.out.println( " Polling Component Activated " );
        Integer period = (Integer)config.get( " period " );
        thread = new PollingThread(
            period!=null ? period : DEFAULT_PERIOD);
        thread.start();
    }
    protected void deactivate() {
        System.out.println( " Polling Component Deactivated " );
        thread.interrupt();
    }
}

Вы просто объявите вашу ссылку на другие услуги: 

<reference name="LOG"
    interface="org.osgi.service.log.LogService "
    bind="setLog" unbind="unsetLog"
    cardinality="0..1"/>

И вы можете опубликовать свой компонент как сервис:
Это делается с помощью элемента <service> в нашем XML-дескрипторе. 

<service>
    <provide interface="net ... ContactRepository"/>
    <property name="foo" value="bar"
</service>

Предоставьте несколько услуг, просто добавив дополнительные элементы <provide>.
Укажите свойства службы, используя элемент <property>. Эти свойства передаются компоненту при активации и публикуются в реестре сервисов

...