Wednesday, April 6

OSGi in Action in print

Just heard from Manning (publishers of OSGi in Action) that our book will be in print tomorrow!! This is great news - thanks again to my co-authors Richard, Karl, and David; as well as all the managers, editors, and graphics people at Manning who put up with us for so long!

Free chapter samples are available from http://manning.com/hall/, but there's nothing quite like having a physical copy lying around on your coffee table ;)

Sunday, June 28

OSGi vs Jigsaw, JSR 330 vs 299, OBR vs P2, Maven vs ...?

While I enjoy a good technical discussion I try to avoid conflict where I can. So it's somewhat worrying to wake up and realize that all the projects I work on are involved in heated debates!

The most obvious one is between OSGi and Jigsaw - now personally I have no issue with a modularity system that's optimized for the JVM. Having done time as a JVM developer I realize that often what's best for the JVM is not what's best for applications, and vice versa. Sometimes you just need shortcuts that you can trust to 'internal' users but would be dangerous if exposed to everyone, for example the Unsafe class. That said, I would be cautious in using Jigsaw for modularity outside of the JVM - this is not based on any technical point at the moment, it's purely inertia on my side while Jigsaw is being fleshed out. I don't have much spare time and I'm currently in my comfort zone with OSGi.

My hope is that JSR 294 can act as a bridge between OSGi and Jigsaw by standardizing some of the details needed to declare and define modules - like naming, version ranges, imports, exports, etc. We could then use JSR 294 metadata to configure OSGi bundles in place of the dependable (but non-type-safe) manifest, removing a major bugbear of new developers. Unfortunately it looks like JSR 294 might fudge this issue and go with opaque strings that only the target module system understands :(

In my ideal world JSR 294 would define a small common module API without trying to standardize a complete module system. Trying to capture too much detail can lead to long, contentious discussions and puts a straightjacket on future solutions. Specifying not enough (opaqueness) makes portability a joke.

Does this sound familiar? This is essentially what's happening with JSRs 299 (Contexts and Dependency Injection) and 330 (Dependency Injection for Java). JSR 299 defines the API and semantics for a complete dependency injection system for Java EE, whereas 330 is defining a much smaller API that just covers injection points and configuration in Java SE. Ideally people could code to the smaller 330 API to gain some portability between DI frameworks without having to rewrite or use a completely different API for the more complete JSR 299 specification. Developers can choose the level of portability they want.

While there has been some recent friction on the JSR 330 list, it does look like people are making significant concessions to standardize this reduced API. This is great news for people like me who provide DI extensions (in my case peaberry) because by adopting this API my extension could conceivably be used with Guice, Spring, or any other framework that supports JSR 330 - even fully-fledged JSR 299 systems.

Now if the same thing happened with JSR 294 I could package peaberry so it could be used as an OSGi bundle, or a Jigsaw module, or even as an element in some future modularity framework I've not yet heard of.

Unfortunately finding the sweet spot between defining too much and too little is a hard process, and isn't helped by personality clashes. Another example of this is the recent flare up between P2 and OBR... both provide a form of requirement/capability model to help decide what bundles should be deployed to satisfy a given need, but P2 goes further and defines additional details necessary for Eclipse installations. That doesn't mean they can't co-exist or there isn't a common subset of metadata they could share, which is what RFP 122 is hoping to achieve.

Indeed the Nexus Maven repository manager (Professional Version) already supports P2 and will support OBR in 1.3.5 - and when the updated OBR spec is finalized I'm sure it will be just as straightforward to handle that as well.

The last project from my title is Maven - a name associated with peace, harmony, and logical discussions that has never been involved in this kind of dispute ;) Seriously though, it is interesting that the next version of Maven may be based on both Guice (hopefully using the JSR 330 API) and OSGi (abstracted via the JSR 330 API using peaberry). Its artifact resolver will probably be pluggable, allowing it to take advantage of both P2 and OBR metadata.

So in the end these spec discussions are not the end of the world: even without agreement it is often possible to map between different forms of API and metadata. Of course it is much easier if things like version formats are standardized (any chance of this 294 gurus?) but even with opaque strings I bet someone will end up writing a Jigsaw-OSGi adapter...

Tuesday, May 5

Distributed OSGi with Newton + peaberry

Last week I finally got around to testing peaberry with the Newton distributed OSGi framework from Paremus. It was surprisingly easy to use peaberry with Newton, I only had to make a couple of changes to support native LDAP filter strings when querying the OSGi service registry:

   http://code.google.com/p/peaberry/issues/detail?id=34

These changes are now available in the 1.1.1 release of peaberry. I've also written up a distributed OSGi example based on the existing Spring example.

The new example unpacks on top of a binary installation of Newton 1.3.2 and shows how you can use property files to switch between local and remote services without changing your compiled Guice bindings.

While writing the example I realized that there are a lot of cool abstractions we can build on top of the basic peaberry API. I'm trying to follow the model used in both Guice and OSGi and keep the core API as simple, lean, and mean as possible while providing ways for others to build even more user-friendly layers, such as BindForge, on top.

There are two essential layers I would like to add in the next peaberry release:
  • Configuration - but not tied directly to the OSGi CM service

  • Lifecycle - but again, not tied directly to Bundles and Activators
which will hopefully make it really easy to configure and tie services together.

I'm also considering adding extender bundles to scan for service annotations or scrape 'blueprint' XML and dynamically configure the relevant bindings at runtime, but that would be more of a 1.3 feature. If you're interested in building on top of peaberry, or you have an interesting idea for a new feature, please let me know.

Until then take a look at Newton+peaberry and see distributed OSGi in action!

Saturday, March 28

peaberry - EclipseCon slides now available

My EclipseCon talk on peaberry seems to have been well received, although I think it would have been even better if I'd reduced the technical content to allow time for more questions. I always find short talks harder to plan than long talks, and this was a good learning experience.

If you missed the talk you can either view it on gPublication or download the original presentation.

Of course hearing from my boss that he was closing our company the night before didn't really help. But I'm glad I got the chance to visit EclipseCon one more time and expand my network, which will come in useful for my upcoming job search.

So if you know of any companies interested in hiring someone with good Java, OSGi, and Maven skills... let me know :)

Thursday, March 5

maven-bundle-plugin 2.0.0 released!

The Apache Felix team is pleased to announce the release of maven-bundle-plugin 2.0.0

This release uses the latest bndlib (0.0.311) which requires you to build with a Java5 JDK. You can continue to target earlier JVMs while building with a Java5 or later JDK by setting the source and target levels in the maven-compiler-plugin configuration.

Here is the list of issues fixed in this release:

Bug

  • [FELIX-545] - Export-Package version inconsistencies.
  • [FELIX-546] - Import-Package version inconsistencies.
  • [FELIX-549] - Import-Package should not include "snapshot" from snapshot dependencies
  • [FELIX-660] - "Class in different directory than declared" error when bundle classes in a directory other than bundle root
  • [FELIX-677] - Parser throws error when DynamicImport-Package contains attributes
  • [FELIX-699] - manifest goal does not interprete _include instruction correctly
  • [FELIX-782] - Manifest goal ignores version attribute specified in _exportcontents
  • [FELIX-807] - conversion of JAR into bundle fails if there are classes is the default name space
  • [FELIX-831] - bndlib unnecessary modifies valid OSGi Bundle-Version numbers (update to bndlib 0.0.293)
  • [FELIX-843] - Regression: BND 0.0.295 does not augment Ignore-Package with excluded import packages
  • [FELIX-850] - Wrong symbolic name computed when groupId is a single segment string.
  • [FELIX-864] - A wrong symbolic name is calculated if artifactId starts with lastGroupIdSegment-.
  • [FELIX-899] - Version attribute missing from Import-Package on provided dependencies
  • [FELIX-907] - Regression in latest BND code: negated exports are applied to private packages

Improvement

  • [FELIX-684] - Enable excludeDependencies to check groupId, version, etc. rather than only artifactId
  • [FELIX-806] - changing the internal configuration of the archive plugin doesn't seem to be possible
  • [FELIX-941] - Support singleton & fragment-attachment directive generation

New Feature

  • [FELIX-912] - Improve default Export-Package / Private-Package settings by scanning the project source
A quick bundle example using the classic Maven quickstart project:

  mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app

# edit the pom.xml, change packaging from jar to bundle and add:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>2.0.0</version>
        <extensions>true</extensions>
      </plugin>
    </plugins>
  </build>

  mvn clean install
# you should now have a valid OSGi bundle

plugin docs: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
plugin FAQ: http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html
bnd docs: http://www.aqute.biz/Code/Bnd

--
Regards, the Apache Felix team

Friday, February 27

maven-bundle-plugin 2.0.0 coming soon

Just started a vote for the next major release of the maven-bundle-plugin, if all goes well it will be published to Maven central next Wednesday (4th March).

Sunday, February 22

Guice feature comparison

Yesterday Jesse added this table to the Optional AOP page of the Guice wiki:

Guice 1.0 Guice 2.0 Guice+AOP 2.0 GIN
Library size 544Kb 420Kb 640Kb 0Kb (code gen)
High performance
Binding EDSL
Scopes
Typesafe
Fast reflection ✔ (cglib) ✔ (cglib) ✔ (code gen)
Line numbers in error messages
Method interceptors
Provider Methods
Binding overrides
Tool-friendly SPI
Child Injectors
Servlet Support Scopes Only
Error Reporting Good Better Best Best

I think it's a great summary and shows how flexible the new release will be.

Tuesday, January 13

Guice-Peaberry vs Spring-DM

six times as fast, half the size!

Of course it's never that simple, these are just some fun measurements I took today using a trivial testcase that injects an OSGi service. They completely ignore functionality, flexibility, usability, and many other *bilities... flame-on!