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

Question

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

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

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

Answer 1

Очень хорошее сравнение (с 2007 года, я думаю) на EclipseZone: A Comparison of Eclipse Extensions and OSGi Services.

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

Answer 2

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

Я призываю вас, чтобы проверить это хорошее введение в декларативные услуги в данной презентации:
Component Oriented Development in OSGi with Declarative Services, Spring Dynamic Modules and Apache iPOJO, от EclipseCON2009.

Вот вкус:

---

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

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

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

Как и все удлинители, DS выполняет задачи от имени других пачек. Спецификация DS определяет этот расширитель и реализуется с помощью фреймворков.
Сам комплект расширителя называется Сервисный компонент Runtime или 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. Это нарушило полярность компонента.

Таким образом, вместо wrinting в "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"/> 

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

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

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