Monday, October 29, 2012

Back from ECE/OSGi Community Event 2012

I am slowly getting my shape back after a very exhausting week, full of interesting discussions and beers at Hotel Nestor's bar!

I'm very glad I had the opportunity to meet many peers of the Eclipse and OSGi communities, and even get some work done. I discovered some cool stuff and ideas I plan to use on my projects (look at this for instance), and hopefully discussions we shared over beers with plenty of smart devs will grow into interesting software.

Notably, I met the guys behind the NativeOSGi initiative (Alexander Broekhuis, Sasha Zelzer and Steffen K├Ąchele). They all wrote a C or C++ OSGi-like container and are now planning to merge their efforts and propose an RFP to the OSGi Alliance with the support of David Bosschaert. I am already using one of the containers at work and wrote a C++ port of Declarative Services to make it easier to program and design. I gave my talk called "Universal Declarative Services" (a pun on Universal OSGi) where I presented the port and a model-driven approach to component design to make the implementation back-end (Java or C++/native) transparent. You can have a look at the slides.

The OSGi tooling BoF was a rich event. It was kinda hijacked into becoming an "OSGi adoption howto" BoF but it was very welcome as well. The room was full, with maybe 60 people, so I guess the interest in OSGi is getting stronger.

The president of the OSGi Alliance, Richard Nicholson, asked what were the main hurdles preventing OSGi adoption. From the discussion that ensued, the 3 top problems were:
  • Tooling
  • Education 
  • 3rd party libs that are not bundles upstream
The tooling problem is a recurring observation, but it is being addressed by environments such as BndTools or bnd embedded in different build systems (Maven, SBT, ...). There is still no consensus on code-first or manifest-first, because of the argument that "good engineering of modularity requires you to think about dependencies first". Still, that doesn't make the manifest the right tool to think about them, and BndTools can show you during development time what will be the calculated imports. 

Tooling is more than just "making" bundles: it's also designing them, deploying them and getting them nicely. Regarding the latter, there is a need to support OSGi R5 repositories (OBR's successor, or OSGi's sanctioned alternative to p2) in Sonatype Nexus, an artifact repository manager originally designed for Maven repositories. We started looking at a solution with Neil Bartlett (who is maintaining repoindex, the official OSGi R5 repository indexer and successor to bindex), so if you're interested drop me a line.

The second point was education: it's not only a matter of university courses, as it was pointed out people really learn to "code" during their first year at work rather than during their studies. Unfortunately this is not the best recipe for change, since many workplaces don't really do modular software. There was talk on how companies prefer to do things over and over again rather than try to get them done "proper" once. Obviously, proper is more and more difficult as the size of your problem increases, so you have to reduce your problem to its simplest form and then you can tackle it and try get it "right". Even then it might not be done right yet, but if it's in an isolated module, with explicit dependencies, it's much easier to evolve (and if you use semantic versioning it's even easier because you know what is broken!).

There is no clear solution to education yet, but I guess blogging is a start :).

The last "top" problem was the lack of 3rd party libs, but I guess the root problem is that getting "into" OSGi can be painful when you have not only the OSGi way to learn, but also have to fight just to use your favorite JAR. Life would be much easier if you could simply use all the most used Java libraries in your OSGi container without any second thought.

I had been doing some work with slf4j (and I plan to propose a patch soon), and seeing these 60 experienced OSGi users in the room I proposed that we could all "Adopt a Library": the plan is not only to add the proper metadata (that's a required start and Glyn Normington already did a lot of work for EBR that's available on GitHub) but also try to make them fit nice with OSGi/modularity and try to evangelize modularity to its core developers. It's also not about trying to reproduce SpringSource's EBR or Eclipse Orbit but try to have the changes approved upstream, because Java developers want to use the latest 'official' version from Maven Central. An OSGi R5 repository would be nice, obviously, but I think Java developers new to OSGi have enough on their plate so we can't ask them to change all their old habits at once :-). 

The idea was well received and I think it was Graham Charters who proposed to ask Black Duck Software (who provide the Ohloh open-source projects statistics) for a list of the most used open source Java libraries and find those that are not OSGi-ready yet. Let's see where it leads us. I think the OSGi Alliance might blog about this some time so even if you were not at the BoF and are interested let them know!

Monday, October 15, 2012

OSGi-friendly APIs

Many existing Java libraries do some classloading for a reason or another. This is the case for SLF4J: it loads its implementations by expecting a class org.slf4j.impl.StaticLoggerBinding in the classpath (and does the same for Markers).

The technique does make sense for the sake of simplicity and to support a large variety of Java setups. However, it would be nice to make it optional, so that people using OSGi or IoC frameworks can implement the bindings differently without having the "legacy" code.

I just made such a proposal to the SLF4J team. I don't really know what answer to expect, but I hope the solution will be adopted sooner or later :).

We'll see :)