New Maven Scr Plugin in sandbox

[Carsten Ziegeler <cz...@apache.org>]

Hi,

Felix and myself (well, basically Felix has done all the work and I did
just some minor enhancements) have put a new maven plugin into my sandbox.

The scr plugin generates the configuration file for the declarative
services based on javadoc tags in the source code. It generates the
component and metadata descriptors. Using the plugin is very easy if you
are also using the maven-bundle-plugin. Just add the scr plugin:
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-scr-plugin</artifactId>
        <executions>
          <execution>
            <id>generate-scr-scrdescriptor</id>
            <goals>
              <goal>scr</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      ...
    </plugins>
    ...
  </build>

And add the javadoc tags to your source code, and everything else is
done by the plugin. For example adding a component just requires to add
a "@scr.component" to your javacode.

You'll find documentation here:
http://felix.apache.org/site/maven-scr-plugin-sandbox.html

This plugin makes developing services for OSGi very easy as you just
have to specify a few javadoc tags.

WDYT?

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: New Maven Scr Plugin in sandbox

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Montag, den 06.08.2007, 09:15 -0700 schrieb Steven E. Harris: 
> Carsten Ziegeler <cz...@apache.org> writes:
> 
> > And add the javadoc tags to your source code, and everything else is
> > done by the plugin.
> 
> Is there a reason that you chose Javadoc tags over Java annotations?

Yes, we are bound to Java 1.4 right now and therefore cannot make use of
any Java 5 features. Furthermore, I had a pressing need for a solution,
so using Qdox with Javadoc tags was easier to use than Commons
Annotations. That's all.

> 
> > WDYT?
> 
> There are some facets specified in these tags that I'd be reluctant to
> include in the source code for the affected classes. Deciding which
> classes should be exposed from a bundle as services feels like it should
> be part of the bundle-level declarations, not bound to the classes

Well, generally, it is the Class Programmer, which has to decide whether
to declare a class for declarative services. She also knows about
required services (references) and provided services (if at all).

Whether the programmer now creates a declaration manually besides the
source file or inlined is a matter of notation. The plugin only extracts
the tagged information and generates the OSGi specified declaration at
compile time.

So, full control remains with the programmer while the end product (the
bundle) has the declaration in the right place - in
OSGI-INF/serviceComponents.xml by default - and referenced with the
Service-Components header.

One issue of course is extensibility: If component A in Bundle BA is
extended by Component B in Bundle BB, we would want to also inherit the
declaration of component A for component B without having to duplicate
everything. For non-abstract classes, this would be possible by just
extending the existing declaration. For abstract classes, this is not
possible as those are not actually declared.

So we introduced another file, which just contains the relevant
information for extension.

> involved. Similarly, specifying which services a given class depends
> upon (say, by way of a filter) also feels too specific to be bound as
> part of the source code.

That is true. Therefore, the spec allows configuration to supply this
reference functionality with a ServiceName.target property (where
"ServiceName" is the name attributed to the reference) containing a
filter string to be used to select the actual services to be referenced.

See sections 112.3.4 (Selecting Target Services) and 112.6 (Component
Properties) for more information on this.

> 
> The plugin looks like a nice solution and it's well thought out. My
> criticism is not meant to attack the plugin itself, but more to question
> whether it's encouraging specification in the right place or at the
> right level. For the record, I have many of the same reservations about
> Google Guice.

Absolutely agreed. But then, the plugin adds no runtime functionality.
It is just to simplify development of standard Declarative Services with
support for the MetaType specification and hence the Configuration Admin
Service.

The only non-standard contents of generated bundles is the additional
descriptor file for abstract components.

Hope this helps.

Regards
Felix

Re: New Maven Scr Plugin in sandbox

["Steven E. Harris" <se...@panix.com>]

Carsten Ziegeler <cz...@apache.org> writes:

> And add the javadoc tags to your source code, and everything else is
> done by the plugin.

Is there a reason that you chose Javadoc tags over Java annotations?

> WDYT?

There are some facets specified in these tags that I'd be reluctant to
include in the source code for the affected classes. Deciding which
classes should be exposed from a bundle as services feels like it should
be part of the bundle-level declarations, not bound to the classes
involved. Similarly, specifying which services a given class depends
upon (say, by way of a filter) also feels too specific to be bound as
part of the source code.

The plugin looks like a nice solution and it's well thought out. My
criticism is not meant to attack the plugin itself, but more to question
whether it's encouraging specification in the right place or at the
right level. For the record, I have many of the same reservations about
Google Guice.

-- 
Steven E. Harris