Me, OSGi and Maven

I don’t like Maven. That’s just how it is. And I whine a lot about it (probably unnerving some of my colleagues).
But I have to admit it’s usefulness. As long as there is no other tool that gives me all the nifty things I will have to stick with it (and abandon it the moment something better shows up).
I love OSGi. I like the things you can do with it. Right now there’s a chance to use it in one of our projects.
The only problem: OSGi and Maven don’ really play nice together.
At least that’s what I thought.
After writing this post and looking back at what I had tried in the past weeks I have to rethink my opinion on that.
There are several different approaches for getting Maven to build OSGi-apps, it’s just that you really need to know what you want to do.
I want to use this post to give a brief introduction to the different approaches and show their weaknesses and strengths.
Here we go.

Maven and a MANIFEST-generator

 

Tools like BND (created by Peter Kriens, the well known OSGi-evangelist) and Bundlor (created by the spring project) are used
to:

• turn exisiting jars into bundles

• package the results of a build process as a bundle

Both tools analyze the classes to figure out their imports and exports and generate a MANIFEST.MF from this information.
They take commandline arguments and can be configured via config-files to deal with special cases.
The Maven/Ant integration they provide is good and easy to use.
Looking at their capabilities and intend I would say they are best suited for the following scenarios:

• OSGifying an existing build process. You won’t have to make changes to your build process to add bundle information to your libraries.
• Projects that are ment to be deployed into an OSGi-enabled framework, like a web application.

Often enough that’s already enough.
Just be aware of the problems this approach may cause.
The biggest being dependencies not being available as a bundle.
Maven has no idea what a bundle is. It will satisfy the build dependencies for your bundle from Maven repositories which in turn can’t guarantee that a downloaded jar is a bundle.
Still today I come jars containing a valid bundle manifest which references libraries that are simply not available as a bundle.
Here it starts to get really painful as I will have to handle these dependencies manually by either converting existing jars into bundles or downloading them manually from an OBR.
This is ok for small projects but can become a very tedious task the bigger it gets.
The second problem is that sometimes it’s unavoidable to duplicate dependency information between the maven dependencies and the MANIFEST-generator. Duplicating information is never a good thing.

Pax-Construct

 

The whole pax suite is something I would recommend to everyone getting started with OSGi. It provides a lot of good tools for handling and learning OSGi.
Right now I want to focus on pax-construct, a nice collection of helper scripts for Maven-OSGi-integration.
Pax does everything from creating the basic OSGi-maven project to adding dependencies and maintaining OBRs.
It’s even possible to deploy created bundles directly into an OSGi-framework of your choice.
Actually, it does such a good job it made it into Sonatypes Maven-handbook.
But I am still not 100% happy with it.
Pax does everything right and gets the maximum out of Maven that is currently possible. There are just some things Pax can’t fix without actually changing Maven.
Once again it’s dependency management.
Pax does a good job in hiding duplicated dependency entries through its scripts.
But I still won’t get around handling dependencies manually. A lot easier than it is with plain Maven, but it’s still a manual process.
It provides an easy way for converting jars into bundles and helps downloading dependencies from an OBR . The downloaded bundles are added to a local repository and integrated into the pom. I still have to search for them but at least it’s easier to integrate them.
Pax also provides everything for maintaining my own OBR, again reducing the amount of manual work.
All in all I think ot doesn’t get any better with OSGi and Maven 2. Anything more would require some work in the intestines of Maven. Believe me, I’ve been there. That’s a road you don’t want to go.
Currently I am using Pax for all my Maven/OSGi needs.

Tycho

Taking a peek into the future, the next tool I tried out was Tycho.
Tycho is being built to allow automated builds of Eclipse applications. As Eclipse apps happen to be completely OSGi-based we also get a pretty good OSGi-build tool.
Based on Maven 3 it supports the whole range of OSGi meta data and can use p2 repositories to resolve OSGi dependencies.
Sadly it doesn’t support OBR, but it shouldn’t be too hard to add support for it (I don’t like p2, something I might explore in another post).
The combination of Maven 3 and OSGi is quite sexy and simply works. It’s exactly what I expect from a build tool.

• no duplication of dependency information
• can use OSGi meta information

This time my problems are not technology but maturity problems.
Maven 3 is currently only available as an alpha version and I don’t really know when the final release is about to appear. When it appears it will probably take quite some time until I will be able to use it in a production environment.
That aside, Tycho is the project to keep a close look on.

Sigil

Sigil is a tool I came across just recently.
It was originally created at Paremus as a tool they used for their own projects, facing the same problems I face.
Instead of fighting Maven they decided to do their own build tool and started the Sigil project.
The result is a very slick and lightweight tool with a nice (Eclipse-only) UI integration .
Compared to Tycho it sticks a little closer to OSGi by using OBRs for dependency resolution.
It manages the creation and maintenance of OBRs.
The tool has been donated to the Felix project a while ago and is currently close to finishing the restructuring process.
There is no downloadable available while I am writing this but it is very easy to get the source and build it (it actually just requires running a script).
Being a completely new tool and lacking the Maven ecosystem I currently don’t see a chance for getting it into our build process.
Nevertheless, It’s a great tool and I am using it for my personal projects.

Conclusion

After getting burnt using Maven 2 and OSGi together I started working on this without any expectations.
Now that I am done I have to admit: things look better than I thought.
Not really good but not bad either.
There are quite a lot of hacks involved to make Maven play along nicely with OSGi. Tools like pax do a great job hiding these hacks.
To be really satisfied I will have to wait for the next generation of build tools.
Hopefully Tycho and Sigil start gaining more attention.
Soon.

Cheers,

Jochen

Advertisement