Home > groovy, osgi > Introducing groovyx.osgi: OSGi DSL for Groovy

Introducing groovyx.osgi: OSGi DSL for Groovy

Programming for and in an OSGi environment is sometimes hard. Getting started is hard as well. groovyx.osgi helps both setting up an OSGi environment and simplifies programming by providing support for easy access to OSGi services, etc.

Setting up an OSGi environment

Setting up an OSGi environment is hard work: you have to download an OSGi implementation (usually Apache Felix or Eclipse Equinox, but there are others as well). Then there are many dependencies to download. There is an excellent tool, which simplifies the startup part: Pax Runner. Pax Runner can resolve dependencies from URLs or Maven repositories and start the OSGi framework.

One problem remains: you need to download Pax Runner and the configuration is a (set of) static text file(s). To simplify things and allow scripting in the “recipes”, the module groovyx.osgi.runtime (README) provides a nice Groovy DSL for creating and starting an OSGi framework.

Features:

  • provision bundles from filesystem, web, Maven repositories
  • run Eclipse Equinox or Apache Felix OSGi runtimes
  • flexible Groovy DSL, fully programmable
  • lifecycle callback closures

The dependency resolution code is derived from Grails and was written by Graeme Rocher.

Simple example:

A more complete example including automatic download of dependencies can be found here. Another example provisions an entire OSGi environment including Apache Felix WebConsole on port 8081.

Simplified Programming Model

The OSGi programming model is based on services (or micro-services, as Peter Kriens likes to call them), which are accessed via the BundleContext. Services are dynamic, they can come and go any time during the lifetime of an OSGi application. This is both a strength, as an application can be extended or updated without application shutdown, and a weakness, as it requires careful handling of service dynamics.

Looking up and using a service requires a lot of boiler plate code. A simple example in Java:

The equivalent Groovy code using module groovyx.osgi looks like this:

The groovyx.osgi module (README) contains helper classes to make OSGi programming easier. This package was inspired by ScalaModules.

Features:

  • simplifies working with OSGi service registry
  • safe access to OSGi services, without fear for OSGi dynamics
  • Service finder DSL
  • OSGi service filter DSL.

The filter support is derived from the filter4osgi project and was contributed by Hamlet D’Arcy.

An overview on basic usage of Groovy with OSGi can be found at the Groovy Homepage.

Source code and binaries

groovyx.osgi and groovyx.osgi.runtime are released under the Apache 2.0 license. The code is available at GitHub.

You can either download groovyx.osgi and groovyx.osgi.runtime 0.1 from GitHub or install it using Grape, Ivy, or Maven from the Maven repository at https://github.com/jetztgradnet/repository/raw/master.

A simple example using Grape:

This script is executable with nothing but Groovy (>= 1.7.5) installed.

Roadmap

The following items are planned for the next releases:

groovyx.osgi

groovyx.osgi.runtime

  • add support for pre-defined provisioning profiles
  • add support for OSGi ConfigurationAdmin
  • improve handling of external OSGi runtimes
  • improve docs

Grails OSGi plugin

Final thoughts

OSGi provides no silver bullet for modularization, but it greatly helps, once you wrapped your head around bundles, services and dependencies. It’s not always an easy road, but there are many helpful tools and people out there. I hope, groovyx.osgi can help you to create great applications. Have fun playing in your OSGi sandbox and don’t forget to send me your thoughts. Any feedback is greatly appreciated, either in the comments or open a issue at GitHub.

Fork me on GitHub
Categories: groovy, osgi Tags: ,
  1. January 19th, 2011 at 19:02 | #1

    Very interesting work! However, I think your life would be a lot easier if you based your service handling on Declarative Services (DS) instead of trying to do this in code. Look at for example the bnd annotations how simple you can annotate code to create the required XML.

    Dynamics are trivial with DS … one should rarely have to interact with the service registry.

    Thanks! Kind regards,

    Peter Kriens

  2. jetztgradnet
    January 19th, 2011 at 22:46 | #2

    Hi Peter,

    I also think DS helps to avoid many pitfalls. But if you need to interact with the service registry by code, there is a Groovy DSL for you :-)

  1. January 18th, 2011 at 18:35 | #1