The OSGi (http://www.osgi.org/) framework is a powerful Java tool providing component based service and dependency management. OSGi components can be remotely installed, started, stopped, updated and uninstalled without shutting down your application. Also, OSGi provides far greater dependency management than the basic Java classpath mechanism, allowing you to specify specific versions of dependencies and keep dependencies private so that other components cannot load them. One of the most notable usages of OSGi is the Eclipse Plugin Container. A good starting point for more information is the Wikipedia page http://en.wikipedia.org/wiki/OSGi and the Further Reading section of this document.
Loading Groovy as an OSGi service
The Groovy jar files are released with correct OSGi metadata, so they can be loaded into any OSGi compliant container, such as Eclipse Equinox or Apache Felix. The metadata can be viewed by looking at the jar file's MANIFEST.MF file. For instance, your Jar manifest might contain these lines:
This declares to the OSGi container that the Jar is version 1.7.0 and provides the specified packages for import by other components.
The following examples all use the Eclipse Equinox container, which can be downloaded from the Internet or found in an Eclipse installation.
Perform the following steps to install and start the Groovy Jar in an OSGi container:
Start the OSGi container in console mode:
This should bring up an OSGi console prompt:
You can see the system status of the container at any time using the "ss" command.
Install the Groovy jar file using "install" and a file URL to your groovy-all jar:
The container will assign the bundle an identifier. Start the bundle using the "start" command:
Verify the bundle is started using "ss":
You can list all the packages the Groovy bundle provides with the "packages" command:
Writing a Groovy OSGi Service
Once the Groovy jar is loaded into the container, writing an OSGi service that uses Groovy is as simple as creating a subclass of the framework's BundleActivator class.
The Activator's start(BundleContext) method will be invoked when the container starts the service, and the stop(BundleContext) method will be invoked when the container stops the service.
The first step in deploying the new Groovy service is to create a jar file containing the Activator. The manifest for the Jar needs to specify the name of the new service, the version, the fully qualified path to the Activator, and which packages from the groovy-all jar bundle to import. The complete manifest for this example follows:
The Import-Package statement is important. It states all the dependencies from the Groovy-all jar which are allowed to be referenced. The Groovy-all Jar exports many, many more packages than just this... an Import-Package definition with just enough dependencies to get the println to work correctly is shown here. In a more meaningful Activator you'd want to import many more of the packages.
The complete Jar for this example has a layout as follows:
Test the new Hello-Groovy bundle by running the OSGi console and issuing the following commands, using "ss" to verify that the correct dependencies are loaded beforehand:
The start and stop message shows that the Groovy service was correctly started and stopped.
Including the Groovy Jar within a Bundle
Publishing a service written in Groovy
Consuming a service (the groovy-ness of which is immaterial)
Missing Constraint: Import-Package: groovy.lang; version="1.7.0.beta-1-SNAPSHOT"
Sunil Patil wrote a 3 part writeup with full code listings on JavaWorld. Part 1 details the basics os a Hello World service. Part 2 describes the Spring DM product and adding Spring to OSGi. And Part 3 covers several web deployment scenarios and issues. Also, Joseph Ottinger h