The programme for the Birds-of-a-Feather (BOF) session at OSGi DevCon 2012 – co-hosted with EclipseCon 2012 – has been announced. I will be speaking about the Java 8 module system, Jigsaw and how they relate to OSGi: what are the differences; the pros and cons of each in different environments; and the potential for them to work together.

There will also be sessions on: OSGi Subsystems; simplifying development with the upcoming OSGi Bundle Repository (OBR) standard; and finally a surprise session from a mystery speaker.

The BOF is free to attend, you don’t need to be registered for OSGi DevCon/EclipseCon. So if you’re in the Washington DC area and interested in learning more about OSGi or meeting several of the top OSGi experts… you know where to go.

I will be running a series of OSGi training courses this year, with the first two being held in London and New York in February. The early bird pricing for London will expire in the next couple of days, so please do hurry to secure your place!

If you’re in North America and can’t make NY in February then there will be another chance to take the training in the Washington DC area (very close to Dulles airport). Then later in the year I will be down in Sydney, Australia.

You might be wondering about the “Masterclass in OSGi” series that I previously ran with Peter Kriens, who recently announced his resignation from the OSGi Alliance. Peter is very busy completing his duties for the Alliance and then will be fully engaged with his next venture, so he has told me that he is not able to participate in the masterclasses for the foreseeable future.

My new course is heavily based on the subjects and discussions that arose from the masterclasses that took place in 2010/11, though it is intended to be more accessible for OSGi beginners. I still believe it’s the absolute best way to quickly achieve a deep understanding and mastery of OSGi and modularity in Java, and I very much look forward to seeing you there.

If you’re a heavy Eclipse user on Mac OS, you’re probably just as sick as I am of seeing the following in your Dock:

… and the following in your Application Switcher:

How on Earth am I supposed to keep track of all those icons?? Well I just can’t, and I’ve been struggling with this nonsense for years. I’ve tried changing the Dock icon, and the name of the application, but these settings are still shared by all the workspaces that run with that copy of Eclipse.

Enough is enough, I need a per-workspace label for my dock icons, so I created a plug-in that I’m calling the Workspace Badge Plug-in for Mac OS. It looks like this:

… and this:

By default it uses the last segment of your workspace path, but there isn’t much space so that often gets shortened with ellipses. So you can set your own short string in the workspace using a preference page:

The amazing thing is, this is probably the tiniest plug-in I have ever written for Eclipse, and is likely to be one of the most useful! If you want to try it out, install from the following update site URL (Marketplace listing coming soon):

http://macbadge-updates.s3.amazonaws.com/

The plug-in has not been exhaustively tested. It works for me on Eclipse 3.7 Indigo. I have no idea what would happen – and take no responsibility for what might happen – if you try to install it on an OS that is not Mac OS.

Pascal Rapicault has written a blog post on his reasons for not choosing OBR as the provisioning technology for Eclipse.

I have absolutely no wish to start a fight, certainly not between myself and Pascal whom I regard as a friend. However it would be remiss not to correct the errors in his post, because that could leave the impression that OBR is an unworkable technology. The fact is that, today, both OBR and p2 are workable technologies for provisioning OSGi applications, but I would argue that OBR is cleaner and more usable, and much easier to integrate. That’s why I am incorporating OBR support into Bndtools at pretty much every level.

The OSGi Bundle Repository draft specification defines a repository index format and a resolver API. It allows us to do the following:

1. Add a repository index (or multiple indexes) to a resolver.
2. Specify the starting environment, for example which platform, which Java version, etc.
3. Add a set of requirements: what we want to get out of the resolver.
4. The resolver calculates the set of required resources that will satisfy those requirements. It also reports optional resources that may enhance the functionality of the selected set.

To address Pascal’s arguments in turn:

OBR focus was bundle centric. No “group” (aka features), no native files, …

Incorrect. An OBR repository can reference any kind of resource. The dependencies between resources are modelled as abstract “requirements” and “capabilities”. So a group/feature can be modelled as a resource that requires a bunch of other resources using their “name” capability.

Naturally, most extant OBR repositories overwhelmingly contain OSGi bundles, but the same is true of p2.

The repository format was fixed and was XML only, no possibility of extension.

Yes the repository format is XML, but it is quite extensible thanks to the generic requirement/capabilities model.

OBR’s format has the advantage of being a single file, repository.xml, compared to p2’s twin files content.xml and artifacts.xml, and it is more readable than either of them.

Each bundle listed in the repository was referring to the payload (the actual jar for the bundle) using a fix URL rather than abstracting the artifact location in a coordinate — like Maven does with its concept of GAV or like p2 does with “artifact keys” — which makes mirroring just plain painful (I know it is possible to provide URL handlers, but come on…).

Incorrect. OBR repository indexes use URIs, not URLs. It is up to the downloader to resolve those to a physical location, just as p2’s downloader must resolve its abstract “coordinates”. Mirroring is therefore perfectly possible. Indeed there is no functional difference between a URI and a Maven “coordinate”, and Maven coordinates can be trivially encoded as URIs.

The provided API was not allowing for transactional state change (some bundles could be installed, but not all the required ones if the download failed).

OBR does not specify how to download resources, it only calculates which resources are required to satisfy the question we asked of it. Transactional behaviour can be built into the code that we use to download those resources. So while this was missing from OBR when Pascal evaluated it, he could have chosen to implement a transactional downloader on top of OBR rather than redesigning the whole repository and resolver.

Since it is a standards document, OBR avoids mandating implementation details such as how to download resources, because whatever is convenient for Eclipse may be inconvenient or impossible in other environments.

The metadata did not accommodate the expression of what needed to happen to the bundle (e.g. should it be started, set the start level, etc.) and thus even less to other things.

State requirements — e.g. the requirement for the bundle to be in active state — can again be represented in the requirements/capabilities model. However it is admittedly non-obvious how to do this, and the latest (non-released) draft of the specification will make this area clearer.

The resolver always insisted on installing all the fragments available (which in complex repos like Indigo means that installing JDT will bring in parts of WindowBuilder since it has some fragment to JDT UI iirc)

The resolver tells us about available OSGi fragments as optional resources. The UI for a resolver (e.g. Eclipse Update Manager) should present those optional resources to the user and allow some or none of them to be selected.

Platform-specific fragments (e.g. SWT) can use the requirements/capabilities model to ensure they are not selected on an incorrect platform. For example, the Win32 SWT fragment would have a requirement of type platform and filter value (&(os=win32)(ws=win32)(arch=x86)). Before running the resolver we would add a “global” capability for the platform we actually want to resolve on.

Why not p2?

Almost nobody believes that p2 was ready to be released when it actually was released, back in Eclipse 3.4 (Ganymede). As a result, installation of plug-ins in Ganymede, and even in the following release (3.5 Galileo) was so error-prone that most Eclipse users reverted to unzipping files directly into their plugins directories.

P2 finally became sort-of usable in 3.6 (Helios), but it still does not support one of the most important aspects of OSGi resolution: uses constraints. That is, the p2 metadata do not support expression of uses-constraints and the resolver algorithm does not take account of them. As a result it is quite easy to get p2 to resolve a set of bundles but later find that those bundles cannot work in the actual OSGi framework.

Uses constraints are fully supported by OBR. It is still theoretically possible to generate a resolution set that does not resolve in OSGi, but this will always be possible unless we use the actual OSGi resolver itself, and under identical conditions. In practice, I have found OBR always produces high quality resolution sets so long as I feed it an accurate set of initial capabilities — in other words, GIGO.

The repository index generator for OBR is a simple command line tool provided in a single small JAR, which can also be used from ANT and Maven (it is already embedded in the Maven Bundle Plugin). In contrast, the p2 generator tool is an ANT task that only runs embedded inside Eclipse. This necessitates firing up a headless Eclipse application from an enclosing ANT build… and naturally you have to have a full Eclipse installation on your build machine.

Finally, last time I checked, the p2 resolver only ran on Equinox, not on any other OSGi framework.

On the other hand, there are certainly some valuable contributions in p2. The downloading, transactional updates, touchpoints etc would all still be useful in a provisioning system built on top of OBR’s repository and resolver.

The Future

Pascal is right to try to identify missing features in OBR, but I feel that he fell into the trap of mistaking one particular implementation — the Felix OBR bundle as it existed back in 2007/8 — with the abstract features of the specification itself. All of the requirements he states could have been implemented alongside an improved OBR bundle rather than throwing out the baby with the bathwater

However, what’s done is done. I’m glad that Pascal has participated in the effort to update the OBR specification, and I hear from my contacts inside the Alliance that the new specification is close to release. At that point I will incorporate the new OBR into Bndtools, and continue to recommend it to my clients who are seeking an OSGi provisioning story.