Eclipse Extensions and Declarative Services

Question

I'm a little confused on the approach to extensions/services in the Eclipse architecture. There are two options available to a developer:

1. The use of Eclipse plugin extensions - http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
2. The use of declarative services - http://www.eclipse.org/equinox/bundles/

When you would use one over the other and what are the advantages and the disadvantages of each approach? Also going forward which is the preferred approach?

Answer 1

The problem with the "current" approach (pre3.5M5, like eclipse3.4), is that both Eclipse plugins extension or OSGI DS (Declarative Services) does require some extension-specific or OSGI-specifc API to be present in your plugin.

I would encourage you to check out this good introduction to Declarative Services in this Powerpoint presentation:
Component Oriented Development in OSGi with Declarative Services, Spring Dynamic Modules and Apache iPOJO, from EclipseCON2009.

Here is a taste:

---

The module layer allows to minimize static dependencies, and fewer static dependencies means less stuff that must be present for your component to work.
Services allow your component to interact with other components.

Components should be implemented as POJOs (Plain Old Java Objects) glued together with OSGi services.

Declarative Services (DS) is a specification from the OSGi Compendium, section 112.
It was introduced in Release 4.0 and is based on the extender model.

Like all extenders, DS performs tasks on behalf of other bundles. The DS spec defines this extender and it is implemented by frameworks.
The extender bundle itself is called the Service Component Runtime or SCR.

The terms DS and SCR are sometimes confused:
DS is the specification, SCR is the actual bundle that implements the specification

There are significant improvements in DS in OSGi R4.2.
Many of these changes are supported in Equinox 3.5M5+.

SCR (the "Service Component Runtime" which is an "extender bundle" implementing the new and improved OSGi R4.2 DS - Declarative Service - specification) will:

• Creates Components.
• Binds them to services and configuration
• Manages the component's lifecycle in response to bound services coming and going.
• Optionally, publishes components as services themselves

You still have a MANIFEST.MF:

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

You will use:

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

SCR will find activate/deactivate methods automatically.
We can call them something else by adding attributes to the XML declaration.

Before R4.2, the method names could not be changed and they had to take a parameter of type ComponentContext, from the DS API. This broke the pojocity of the component.

So instead of wrinting a "BundleActivator" (OSGI-specifc API in your component: BAD), you write a plain POJO object:

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();
    }
}

You will the simply declare your reference to other services:

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

And you can publis your component as a service itself:
This is done with the <service> element in our XML descriptor.

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

Provide multiple services simply by adding additional <provide> elements.
Specify service properties using the <property> element. These properties are passed to the component in activation and published to the service registry

Answer 2

There's a pretty good comparison (from 2007, I think) on EclipseZone: A Comparison of Eclipse Extensions and OSGi Services.

I would follow the conventions of your target platform. So, if you're writing a plugin for Eclipse 3.4, say, create an Eclipse 3.4 plugin (which will use a MANIFEST.MF for dependencies and a plugin.xml for extensions/extension points - the article you link to is for Eclipse 2.x). You can examine the contents of the plugins directory to confirm this.