With the release of the OSGi Enterprise Specification a whole new set of developers will be trying to figure just what the hell you can do with this OSGi technology anyway?

Those who have started to explore it will have found that surprisingly OSGi doesn’t tend (initially) to make development easier, it also doesn’t tend (initially) to reduce the amount of code you need to write. So what then is it good for?

The key feature of OSGi is that it allows for proper modularization of Java software. There’s a lot of good information out there on the interweb about why modularization is important – but the key message is that modularization allows you to decide what are the building blocks of your application. Not at the nuts and bolts level that is Object Orientation and not at the red car or blue car level that is SOA, but at the intermediate level of engines, tires and gearboxes – where most engineers really like to play…

OSGi makes the task of building sets of applications easier. It is not about building one application but about building applications from applications, software reuse, yada yada, or as I like to think of it – turtles all the way down.

All this sounds great, but in order to build good modular software it is important to decide what are the public parts of your architecture, what are the bits you’d rather keep private and which parts you want to inherit from others. This process is achieved in OSGi via importing and exporting packages between bundles. It is also highly advantageous to use the OSGi services model which allows you to neatly hide implementation specific code behind interfaces and plug in and out different providers at runtime.

The problem now becomes that as you depend on more and more bundles the task of managing that list of bundles becomes more and more onerous. Most peoples first experiences with OSGi (mine included) is a frustrating iteration of trying to start a given bundle but getting a loud exception message saying that a given bundle cannot be resolved because some of its dependencies are missing. You then add bundles that satisfy these dependencies but find that these dependencies are transitive, so satisfying the top level dependencies just leads to another deeper search for the bundles that satisfy those dependencies. You finally get all the required bundles installed and activate your top level bundle and click on the web browser or ui and nothing happens. Silly you, you have forgotten to activate the bundles that provided supporting services for your application.

The benefits of OSGi are obsured by the complex task of managing both the api level and service level dependencies. Which bundles do I need installed? Which bundles do I need to activate? If I remove this bundle what are the consequences? If I stop my application what else can be tidied up? All these questions are exactly those we started asking ourselves when we started writing OSGi applications and Nimble is the logical conclusion of this work.

The interesting thing is that Nimble is in fact built upon the very modularity information that is so complex for developers to navigate, all of this information is actually perfect for a computer to make reasoned judgements about. Given a set of bundles Nimble can very rapidly traverse the set of bundles that need to be installed and activated to make your application work, and when you’re done it will tidy it all away again.

Sample JEE application

To see how this works in practice let’s see how to build a traditional three tier application comprised of a web tier, a business tier and a data access tier. For this example we’re going to reuse the AriesTrader sample provided as part of the Aries project. This sample uses six different parts of the OSGi Enterprise specification.

• Blueprint (Spring Beans)
• JDBC
• JNDI
• JPA
• JTA
• Web Applications

When fully installed this application is comprised of more than fifty individual bundles which could be a real headache to download, install and activate manually. However using Nimble this process is easily managed using it’s advanced resolver capabilities and scripting support.

So running the sample…

Before proceeding you should check that your version of Nimble is up to date. You can do this using the “version” command from the cli. This example requires that you have at least version 1.0.14 installed. For information on upgrading Nimble refer to our online documentation.

As Aries is still in the incubation phase at Apache there are not yet any released artifacts we can build against, so if you want to run these samples you will need to check out the source code from svn and build it yourself – there are instructions on how to do this here. To run the Aries trader sample we also need to download and install derby, again instructions can be found here.

Having completed these preliminaries I will create the AriesTrader database which the sample application uses to store its data.

$ mkdir /tmp/aries
$ cd /tmp/aries
$ export CLASSPATH=$DERBY_INSTALL/lib/derby.jar:/opt/lib/derby/lib/derbytools.jar
$ java org.apache.derby.tools.ij $ARIES_SOURCE/samples/ariestrader-sample/assemblies/equinox-test-harness/target/tradeDB.sql

Here I’ve created a sample directory on my machine and created the empty database in that directory.

In fact the aries trader sample is pretty simple and assumes the database is located on the same machine and the sample needs to be run from that directory as it assumes the database is located relative to the Java process. I guess it’s important to say that this is a limitation of the sample and not JDBC/JPA in OSGi in general!! But for this example be sure to run Nimble from the same directory that you created the database in – in my case /tmp/aries/.

Let’s now run the aries trader example using a OSGi shell script. To do this launch Nimble via the Posh shell executable located in the bin directory of the Nimble installation and then run the aries-trader script in the console.

[dave@feynman aries]$ $NIMBLE_HOME/bin/posh
[feynman.local.0]% pwd
file:/private/tmp/aries/
[feynman.local.0]% sh http://chronological-thought.googlecode.com/svn/trunk/nimble-examples/aries-trader.osh
Internal Paremus Nimble Developer License,
expires Fri Dec 31 23:59:59 GMT 2010.
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
----------------------------------
- AriesTrader sample application -
----------------------------------
# Enter aries source location:
/Users/dave/development/apache/aries
Indexing aries:0 -> file:/Users/dave/development/apache/aries/ -> file:/private/tmp/aries/aries.xml
  include=.*target.*jar
  exclude=null
  base=file:/Users/dave/development/apache/aries/
  load=false
Indexed 32 resources
Indexed 64 resources
Indexed 96 resources
Indexed 128 resources
Indexed 160 resources
Indexed 192 resources
Indexed 224 resources
indexed aries:0
Connect to AriesTrader at http://localhost:8080/ariestrader

The first time you run this script it will prompt you for the location of the Aries source folder and will index the osgi bundles you built earlier.

You should be able to verify that the AriesTrader sample is running by browsing to the AriesTrader web application, the address of which is echoed at the end of the aries-trader.osh script. If you want to play around with the AriesTrader application you can populate the database by navigating to the “Configuration” tab on the aries trader web portal and clicking “(Re)-populate AriesTrader Database”. You should see the database data being populated and you can then log in via the “Trading & Portfolios” tab.

A look under the hood

So what’s going on in this example from a Nimble and OSGi perspective? Let’s look at the contents of the “aries-trader.osh” file. To do this we can use the built in “more” command in Nimble:

[feynman.local.0]% more http://chronological-thought.googlecode.com/svn/trunk/nimble-examples/aries-trader.osh

This pages through the contents of the file allowing us to see the contents just like a standard unix more command, one thing to note is that Nimble uses java.net.URI objects in most places where unix would use a file reference so we can more the file directly from the web. So the contents of the file (in bite size chunks)…

tofile = {
 path = $it schemeSpecificPart;
 new File $path;
};
activate = {
  nim add osgi.active.bundle/$it;
};

The first thing I’ve done is declare a couple of closures “tofile” and “activate” that allow me to tidy up boiler plate code that would otherwise be repeated in the rest of the script.

The “tofile” closure converts a java.net.URI object to a java.io.File here you can see that Nimble is able to make reflective calls on Java objects – get methods are camel cased and the return value of the closure is the last object returned.

The “activate” closure just passes the parameter parsed to the “nim add” command which we saw in previous posts to add the specified osgi bundle to this OSGi framework in the active state. I’ve then created some banner code that makes the script a little more user friendly:

echo ----------------------------------;
echo - AriesTrader sample application -;
echo ----------------------------------;

Now we start the work of the script proper. Nimble figures out the bundles that need installing or activating based on indexes, so in order to load the aries bundles we need to generate an index file that describes their requirements and capabilities. The following section of the aries-trader.osh script shows how I created this index:

aries = tofile ($PWD resolve aries.xml);
if { not { $aries exists } } {
  echo # Enter aries source location:;
  read sourceDir;
  source = new URI $sourceDir/;
  pom = tofile ($source resolve pom.xml);
  if { not { $pom exists } } {
    echo Expected aries source directory;
    exit;
  };
  nim index -viI .*target.*jar aries $source $aries;
};

Firstly I check if a file aries.xml exists in the directory where I’ve run this script, if it does then no action needs to be taken, if not then I need to generate an index. To generate the index I prompt the user to tell me the location of their Aries source folder and make a trivial check that it is in fact the Aries source folder by checking if there is a pom.xml file present in that directory. If all is well I then call the nim index command with a number of options that tell Nimble to generate an index called “aries” in this directory based on files that match the regular expression .*target.*jar from the specified source folder. The result being we get an index file aries.xml of all artifacts built by the maven build. We now need to load the indexes.

nim repos -l $aries;
nim repos -l ($0 resolve aries-rules.xml);
nim repos -l springdm;

These three commands add the indexes that Nimble will use to build our application. The first entry loads the aries.xml index we generated above, the second adds a second aries index file that I have pregenerated (more on this in a second) and the third adds an index that points at the Spring Enterprise Bundle repository based on a well known alias name “springdm”. Ok so hang on a minute where does this aries-rules.xml file come from? Let’s take a look at it via Nimble:

[feynman.local.0]% more http://chronological-thought.googlecode.com/svn/trunk/nimble-examples/aries-rules.xml
<repository name="aries-rules:0" xmlns="http://schema.paremus.com/nri/1">
 <rule name="aries.osgi.service/blueprint:0.1.0.incubating.SNAPSHOT">
  <req name="builder/primordial.builder" />
  <req name="osgi.active.bundle/org.apache.aries.blueprint:0.1.0.incubating.SNAPSHOT"/>
  <req name="osgi.active.bundle/org.apache.aries.transaction.blueprint:0.1.0.incubating.SNAPSHOT"/>
  <req name="osgi.active.bundle/org.apache.aries.jpa.blueprint.aries:0.1.0.incubating.SNAPSHOT"/>
  <cap name="aries.osgi.service/blueprint:0.1.0.incubating.SNAPSHOT" />
  <cap name="osgi.service/blueprint.extender:0.0.0" />
 </rule>
 <rule name="aries.osgi.service/jta:0.1.0.incubating.SNAPSHOT">
  <req name="builder/primordial.builder" />
  <req name="osgi.active.bundle/org.apache.aries.transaction.manager:0.1.0.incubating.SNAPSHOT"/>
  <cap name="aries.osgi.service/jta:0.1.0.incubating.SNAPSHOT" />
  <cap name="osgi.service/jta.provider:0.0.0" />
 </rule>
 <rule name="aries.osgi.service/jndi:0.1.0.incubating.SNAPSHOT">
  <req name="builder/primordial.builder" />
  <req name="osgi.active.bundle/org.apache.aries.jndi:0.1.0.incubating.SNAPSHOT"/>
  <cap name="aries.osgi.service/jndi:0.1.0.incubating.SNAPSHOT" />
  <cap name="osgi.service/jndi.provider:0.0.0" />
 </rule>
 <rule name="aries.osgi.service/jpa:0.1.0.incubating.SNAPSHOT">
  <req name="builder/primordial.builder" />
  <req name="osgi.active.bundle/org.apache.aries.jpa.container:0.1.0.incubating.SNAPSHOT"/>
  <req name="osgi.active.bundle/org.apache.aries.jpa.container.context:0.1.0.incubating.SNAPSHOT"/>
  <req name="osgi.active.bundle/org.apache.openjpa:2.0.0.beta2"/>
  <cap name="aries.osgi.service/jpa.provider:0.1.0.incubating.SNAPSHOT" />
  <cap name="osgi.service/jpa.provider:1.0.0" />
 </rule>
</repository>

At the time of writing this file is hand generated, it specifies a number of capabilities that match requirements that are automatically detected from client bundles during the index step above. The capabilities are: osgi.service/jpa.provider, osgi.service/jndi.provider, osgi.service/jta.provider and osgi.service/blueprint.extender. When a bundle is activated that requires one of these capabilities then Nimble traverses its indexes looking for rules that provide these capabilities and resolves the rule plus its requirements. In this case we can see that when a bundle requires the osgi.service/blueprint.extender capability Nimble will install and activate three supporting bundles org.apache.aries.blueprint, org.apache.aries.transaction.blueprint and org.apache.aries.jpa.blueprint.aries.

Here an interesting point is that these osgi.service/xxx.yyy are indirect links to the supporting bundles. In fact if I want to switch to a different provider – say Eclipse Gemini then it is just a case of indexing these bundles instead and Nimble will resolve the bundle dependencies using a different set of providers. I’ll try to do this in a later post when the artifacts are available – stay tuned

The final section of the script loads the aries trader sample bundles:

// trader bundles
activate org.apache.aries.samples.ariestrader.util;
activate org.apache.aries.samples.ariestrader.core;
activate org.apache.aries.samples.ariestrader.beans;
activate org.apache.aries.samples.ariestrader.derby.ds;
activate org.apache.aries.samples.ariestrader.entities;
activate org.apache.aries.samples.ariestrader.persist.jdbc;
activate org.apache.aries.samples.ariestrader.persist.jpa.am;
activate org.apache.aries.samples.ariestrader.persist.jpa.cm;
activate org.apache.aries.samples.ariestrader.web;

Here I’m really focusing on the nine bundles I really need for my application, all of the other bundle dependencies (all forty six of them – which you can see for yourself if you type the lsb command at the Nimble console) are automatically provisioned and configured by Nimble. In fact it is a trivial task to change this script to load the Aries blog sample – an exercise I’ll leave till another post.

So in summary Nimble has allowed us to quickly build up an application with real world components like web services, transactions and databases. We focused simply on top level bundles we require and Nimble resolves and deploys all supporting bundles based on index information that is very easy to generate and reuse between applications.

What’s more for the metathesiophobes (comments on a post card if you know of an actual fear related to dynamic resolution) the resolution path for the dynamically deployed bundles is minutely controllable via the indexes that you add to Nimble – so if you want to prevent certain artifacts from being resolved against because of known bugs etc – simply exclude them from your indexes.

Update: Seems I’m not the only one to have made the turtles reference – Kirk Knoernschild makes the same analogy, probably inadvertently borrowed the same metaphor as I do read his excellent blogs.

I recently gave a brief interview about Nimble to Mitch Pronschinske from DZone. I think it does a good job of explaining what Nimble is all about and where it’s going.

If you’ve adopted OSGi and are using it to factor your applications into modular dynamic systems, then you are probably interested in configuring them in a similarly modular and dynamic way. The OSGi Configuration Admin service is a widely used standard for doing just this.

This post introduces Nimble’s command line interface to the Config Admin service and shows how it can be used to configure an OSGi HTTP Service implementation.

To get started you’ll need to download Nimble (it’s only 55k). On Linux/OS X you can start it using:

$ bin/posh

For windows use:

% bin\posh.bat

This introduction was tested against Nimble 1.0.8. To make sure you’re up to date just type:

% version

at the Nimble prompt, and follow the instructions to get Nimble to self-update if necessary.

The Config Admin service manages property maps identified by Persistent IDs, or PIDs. These come in two varieties, singleton PIDs and factory PIDs. Singleton PIDs are used to configure a single underlying entity, often some sort of service, whereas factory PIDs are used to create and configure multiple instances of some configuration target. Under the covers these PIDs are handled by implementations of ManagedService and ManagedServiceFactory. For more details take a look at this book, or at the spec itself, which like most OSGi specs, is surprisingly readable.

The three commands Nimble provides to help you interact with the Config Admin service are:

• pids: this lists registered PIDs and their property maps
• setpid: this initializes or updates a PID’s properties
• delpids: this can be used to delete one or more PIDs

For detailed usage information invoke the commands with -?.

Let’s work through an OSGi HTTP Service based example. To provision the default HTTP and Config Admin service implementations run:

% add osgi.service/http
% add osgi.service/cm

If you want to see the bundles that this installed just type lsb.

Next we can use the pids command to find out what’s available to configure:

% pids -r
15 org.eclipse.equinox.http.jetty:2.0.0.v20090520-1800
15 F: org.eclipse.equinox.http.jetty.config

All this does is list the PIDs and factory PIDs of the ManagedService and ManagedServiceFactory implementations in the OSGi service registry. In this case there’s only one: org.eclipse.equinox.http.jetty.config, a factory PID, published by the Equinox’s Jetty based implementation of the OSGi HTTP service. This is the one we’ll be using.

Note that as with all Nimble commands pids is installed on demand. You can unload it using load -u pids.

The property which controls the HTTP port is called http.port, so we can create a new HTTP listener at port 18080 by using setpid as follows:

% setpid -f org.eclipse.equinox.http.jetty.config http.port=18080

To confirm that the PID has been set let’s list all PIDs using the pids command:

% pids
org.eclipse.equinox.http.jetty.config/org.eclipse.equinox.http.jetty.config-1263568645437-0 {http.port=1234}

The format here is factory-pid/instance-pid {properties}

To test the service I’m going to use the registerServlet bundle from one of the code snippets on Peter Krien’s site. This registers a simple Hello World servlet with the HTTP service. This bundle is in Nimble’s examples repository. Let’s load this repository and ask Nimble to provision and start the registerServlet bundle.

% repos -l examples
% add osgi.active.bundle/aQute.registerservlet

To see the result go to http://localhost:18080/hello

You can change the port by updating the config as follows. Note that the key used here is the instance PID which may be different for you.

% setpid org.eclipse.equinox.http.jetty.config-1263569144831-0 http.port=18081

The servlet will now be listening at http://localhost:18081/hello. To remove the listener altogether simply remove the PID using:

% delpids org.eclipse.equinox.http.jetty.config-1263569144831-0

You can use pids again to confirm that the PID has been removed, and visit http://localhost:18081/hello to verify that the listener has been removed.

I should end by noting that the PID used here is specific to Equinox’s Jetty based implementation of the OSGi HTTP service. Most implementations of this service are configurable using the Config Admin service, but there aren’t any standards for this.

David Savage has written some great introductory Nimble posts. In case you missed them here’s a quick round-up:

• Nimble OSGI – Resolve, download, and start a Spring DM based web app in a single line .
• And for my next trick – Use the Nimble shell to implement a traditional (no resolver) OSGi file install tool.
• Hello Tatooine – Implement an RFC 147 based Nimble command line interface for the Star Wars Asciimation.

Anyone who has worked with OSGi will be familiar with failed bundle resolutions, such as this:

$ java -jar bin/felix.jar 

Welcome to Felix
================

-> install file:/Users/derek/devl/lib/nimble/com.paremus.util.jlook-1.0.5.SNAPSHOT.jar
Bundle ID: 5
-> start 5
org.osgi.framework.BundleException: Unresolved constraint in bundle com.paremus.util.jlook [5]: package; (&(package=org.osgi.service.command)(version>=1.4.0))
->

In this case the cause of the problem is easily attributed to the attempted start of the jlook bundle. The resolution is not so obvious, unless you are familiar with the unresolved package and know how to resolve it.

Often developers will resort to installing likely bundles to see if they resolve the problem, or perhaps try to identify likely bundles by examining their manifests.

In an ideal world, your universe of available bundles would all be indexed, and rather than attempting to start them using  a low-level tool such as the Felix ‘start’ command, you would use a more powerful OSGi resolver, such as Nimble, which would automatically resolve missing dependencies.

However, there are still times when it is useful to be able to search your local file system for appropriate bundles, without having to configure any resolver.

I wanted a simple command-line tool that could search bundle manifests (and contents) using regular expressions, so I created ‘jlook’:

$ jlook --help
jlook searches archive files and prints lines that match PATTERN in the
contents or manifest. It also searches source files and can recursively
search embedded archives.

Usage: jlook [-OPTION].. PATTERN [PATH | CLASSPATH]..
[truncated -- full usage]

So to find the missing dependency above, I could use:

$ jlook Export-Package:.*@org.osgi.service.command
lib/nimble/com.paremus.posh.runtime-1.0.5.SNAPSHOT.jar:
 Export-Package: com.paremus.posh.api;uses:="org.osgi.service.command";version="1.0.5.SNAPSHOT"
 org.osgi.service.command;version="1.4.2"
 org.osgi.service.threadio;version="1.4.2"
1 match 1 path

This recursively searches all jars below the current directory, looking for any that export the missing package.

The ‘@’ in the PATTERN, is used to force it to match at the beginning, or after a comma, as if we look at the full Export-Package header of this bundle, we see that the target package is not the first export:

$ jlook Export-Package: lib/nimble/com.paremus.posh.runtime-1.0.5.SNAPSHOT.jar
lib/nimble/com.paremus.posh.runtime-1.0.5.SNAPSHOT.jar:
 Export-Package: com.paremus.posh.api;uses:="org.osgi.service.command";version="1.0.5.SNAPSHOT",org.osgi.service.command;version="1.4.2",org.osgi.service.threadio;version="1.4.2"
1 match 1 path

Back to felix, we can try installing this bundle:

-> install file:/Users/derek/devl/lib/nimble/com.paremus.posh.runtime-1.0.5.SNAPSHOT.jar
Bundle ID: 6
-> start 5
org.osgi.framework.BundleException: Unresolved constraint in bundle com.paremus.util.jlook [5]: package; (package=scala)

Unsurprisingly, this just results in the next unresolved package to diagnose

The observant amongst you will have noticed that the next unresolved package is ‘scala’, indicating that ‘jlook’ itself has a dependency on ‘scala’. This is not surprising, as I chose to write ‘jlook’ in Scala, so that I could learn a new language.

This blog is not really about the ‘jlook’ utility itself, but rather about how to deploy responsive Java command-line utilities.

(However, ‘jlook’ is included in the Nimble download if you think you may find it useful; type ‘jlook –help’ for full usage information).

I initially packaged ‘jlook’ as a simple scala script, prefixed with ‘#!/usr/bin/env scala’. This meant it could be deployed with the ease of copying a shell script, but only if the recipient had scala installed.

It was also quite slow, because a JVM had to be created to run ‘scala’ which then had to compile the script, before it could be executed. Start-up time was several seconds, which is unacceptable for a utility that typically runs in less that 1 second.

I next packaged ‘jlook’ as an executable jar. This performed faster, but either had a dependency on the scala library jar, or I had to embed the scala library greatly increasing the size of the utility.

To reduce the size of the jlook jar, I tried using pack200 to unpack the scala library. This worked OK, but the additional execution time for the unpack was significant.

I therefore tried a different approach. I converted jlook.jar into regular OSGi bundle and registered a simple RFC-147 command-line interface and loaded it into Nimble:

$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% jlook Export-Package:.*@org.osgi.service.command
*nimble-ext/scala.library_2.7.5.final.jar                         00:06   4.7Mb
*nimble/com.paremus.util.jlook-1.0.4.jar                          00:00    61Kb
lib/nimble/com.paremus.posh.runtime-1.0.5.SNAPSHOT.jar:
 Export-Package: com.paremus.posh.api;uses:="org.osgi.service.command";version="1.0.5.SNAPSHOT"
 org.osgi.service.command;version="1.4.2"
 org.osgi.service.threadio;version="1.4.2"
1 match 1 path

Notice that Nimble automatically resolves and downloads the scala library dependency.

However, this is less convenient, and probably slower, to use than a simple executable jar:

$ java -jar jlook.jar

Happily, both these issues can easily be resolved:

Posh, like bash, can execute commands given after ‘-c’ on the command line:

$ posh -c jlook Export-Package:.*@org.osgi.service.command

and this could be encapsulated in a ‘jlook’ script:

#!/usr/bin/env posh
jlook $*

This still hasn’t resolved the issue concerning the start-up time for the JVM and loading the Scala library, compared to the execution time of the utility.

Those familiar with Scala will know that the scala compiler (scalac) also suffers from start-up delay due to JVM loading and a solution is provided in the form of the fast scala compiler (fsc).

The first time ‘fsc’ is invoked it starts a JVM in the background. Subsequent invocations of ‘fsc’ simply communicate with the already loaded JVM, and thus run without any start-up delay.

We can use the same trick with a background Nimble instace running an ssh daemon and using an ssh client to execute commands in it.

First you need to create ~/.posh/authorized_keys so that ssh clients can connect without requiring a password, as described here.

Then start a background Nimble instance; we use –instance=-1 so we know which port sshd will listen on:

$ posh --instance=-1 -sc sshd &
[1] 3511
sshd: listening on port 8902

(The -s option to posh tells it not to shutdown after running the specified command).

Now you can invoke jlook (or any other OSGi-based command) using ssh:

$ ssh -p8902 localhost jlook Export-Package:.*@org.osgi.service.command
lib/nimble/com.paremus.posh.runtime-1.0.5.SNAPSHOT.jar:
 Export-Package: com.paremus.posh.api;uses:="org.osgi.service.command";version="1.0.5.SNAPSHOT"
 org.osgi.service.command;version="1.4.2"
 org.osgi.service.threadio;version="1.4.2"
1 match 1 path

Nimble contains a trivial script ‘bin/fpc’ for ‘fast posh client’, which simply invokes ssh, so the above could be also run using:

$ fpc jlook Export-Package:.*@org.osgi.service.command

This is not perfect, as it does not pass the current directory into the running Nimble instance, but it does run in about one third the time of the original executable jar solution:

$ time fpc jlook Export-Package:.*@org.osgi.service.command

real    0m0.125s
user    0m0.010s
sys     0m0.008s

$ time jlook Export-Package:.*@org.osgi.service.command

real    0m0.358s
user    0m0.302s
sys     0m0.041s

Read the rest of this entry »