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!

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 :)

Eclipse Indigo Party in Toulouse today!

I'm quite late for this to be an announcement, so let's just say it's a reminder :). Today in Toulouse, France we will celebrate Indigo's release with a full afternoon (and evening) of presentations about Eclipse at large, organized by our local free software group (Toulibre) and JUG (ToulouseJUG).

There will be talks (in French) of various length on diverse topics including Clojure + RCP, JGit/EGit, MDT Papyrus, EEF/Acceleo, Tycho, XText and more. I will myself be talking about the e4 Project.

It's free to attend, so if you have no plans for this afternoon, don't hesitate to come! And this is the Eclipse Indigo Party so there will be drinks around 8pm.

Have a look at the program.

Back from the EclipseCon

Dear Planet,

I'll contribute to the current flood of EclipseCon slides by posting mine as well! They aren't in the best shape because of the conversion they went through but have a look anyway.

Those are the slides of the talk "An Early Adopter's Retrospective on an E4 instrual app", and you can read more, including the abstract, on the EclipseCon website. I hope you can infer the missing bits from simply reading the slides...

The EclipseCon ended almost two weeks ago already, so I had some time to recover and order my thoughts. To me, the best part was definitely meeting people from the Eclipse and OSGi communities (thanks to the OSGi DevCon being held at the same time and place), discussing various topics and meeting the creators of the projects I'm using. For various reasons, I did not meet everyone I hoped I would, but I'd say I scored a solid 80% :-).

I also had the occasion to chat with some developers of the E4 team about the future of the application platform and some ideas I have about improving the "OSGi experience". Mails are ideal for very technical details (it's easier to type code than to pronounce it :-)) but discussions about the general architecture benefit greatly from face to face meetings.

So, thanks to everyone I chatted with, it was a real pleasure. I came back from California with a project in my to-do list and much more in my mind. All in all, it was an interesting experience.

Preparing the EclipseCon 2011

In two weeks, I'll be flying towards my first EclipseCon... and I would really be impatient if my current schedule wasn't so tight. As it is, I don't have time to realize it's coming so soon!

I've been working on Eclipse technologies -- rather than merely using Eclipse as an IDE -- for about three years now. Around that time, I started reading Planet Eclipse, getting to know who's who and discovering a lot about what the different projects were about. In general, this has been a very interesting read and most of all it's been a great source of ideas.

But there was one period, each year, when reading Planet Eclipse was even more interesting, but also had a bitter aftertaste, seeing pictures of this great party and not being there. Each year, the EclipseCon is the great time where people share their progress, best practices, show their creations and meet.

And this time, I'll be there to show what we've been doing. I have spent this week preparing my talk. We're doing a retrospective on an RCP application, but not just any RCP application. As I just said, I've been reading Planet Eclipse for these last 3 years, and this application was a testbed for a lot of stuff I've been reading here. I'll be honest and tell you if it was worth it, and which of these "technologies" we used made a difference ;-).

Our project is using the E4 Application Platform, released last July (yes, we started on a beta and finished on an early preview!), a way that we call "pure", that is it doesn't depend on any 3.x API that the E4 Application Platform doesn't already depend on (basically, eclipse.core, SWT and JFace); it's built from the ground up on OSGi (our non-UI bundles run on any container) and makes heavy use of Declarative Services; we've built it in an unorthodox way considering it's an RCP app, using Maven (started with Tycho and moved to maven-bundle-plugin recently); we're using Git, Hudson (or soon Jenkins) and Nexus.

Obviously, we're not going to talk about all of this. It's an extended talk but most of us already use Databinding, Declarative Services, Git, Hudson or Nexus, and there are even talks dedicated to these topics so we won't bore you with this. Instead, we'll focus on what the E4 Application Platform brings compared to RCP 3.x, on how diving into OSGi changed our ways, we'll tell you what we thought of Maven to build RCP bundles, with and without Tycho... We'll tell you why we did what we did, what went well, and how we failed. We'll reveal some horror stories and tell you how not to repeat the same mistakes we did.

This project was not just our first time doing an E4 RCP project. It was also a deep change in the way we produced software. When we prepared our talk, we tried to focus on what we thought was most interesting/unknown for the audience. My hope is that if you come hear us, you'll get some early feedback to decide what to use for your next project. We will mainly focus on E4 (and give a primer for those who had no time to check it), because that's a hot topic, but this is really a retrospective about a technological stack based on OSGi, E4 and Eclipse technologies.

In any case, I hope I'll meet many of you in Santa Clara!

I've been pretty busy...

Okay, so I've been behind my "bloggging" schedule. In fact, I've been meaning to write about the Eclipse 4 Application Platform and my proposal to improve the integration with OSGi. The discussion is still going on and it's really fascinating because we're in new territory.

It took me quite some time to feel confident enough to discuss those internals with the rest of the E4 team (some of whom have been developping Eclipse for longer than I even used it, even if I started early in 2002!). My radio silence was due to my relentless exploring of all OSGi resources I could find, including framework code (thank you freedom #1!). That included looking at Equinox, Felix, Peaberry Activation, the OSGi specifications, re-reading through and through Neil Bartlett's OSGi in Practice free book (a true gem), and more! I have been developing with OSGi for quite some time already, but going to the next level was an awesome experience.

I've been wanting to blog about the awesome BndTools as well. Don't get me wrong, I discovered OSGi through Eclipse and PDE, and I think PDE and the OSGi-aware classpath / target-platform system helped me a lot to "get" and learn to think about private packages and dependencies. But when creating many new bundles, manually managing the dependencies starts to feel like a time waste, especially when we can't do it "as well" as what a tool would do. The same goes with writing a lot of Declarative Service components, Bnd's annotations come really handy (and the DS editor in PDE suffers from some serious bugs that mess with your XML, we're now avoiding it at work).

What else? The application I develop at work will soon reach version 1.0.0. It's a custom application for a large industrial client, so what it does is off-topic here. What is more interesting is that it's built using the Eclipse 4 Application Platform as what I call a "pure" E4 application, that is it doesn't use the "Workbench Compatibility Layer" (or anything under the org.eclipse.ui package). It's only using "new API" on this side. Of course, it's built on solid and stable technology such as OSGi (a lot of it, in different ways) and SWT/JFace with DataBinding (no XWT yet). We build it with Hudson and Tycho, and we made a nice custom build because we had to work with many legacy components and some requirements on how the application should be deployed. Since I believe we are among the firsts to make a pure-E4 industrial RCP app, I have proposed an extended talk at the Eclipse Con to discuss it, and tell our experience! We'll be happy to tell you our mistakes so you can avoid doing them, and discuss how good E4 is for RCP applications in general.

Finally, I'll be giving a long talk on Scala at the Toulouse JUG this Thursday (December, 2nd). The talk will be in French, but the slides are in English. If you're around Toulouse, feel free to come but I've been told it's better if you register on the website (it's free, but it helps the organizers). I've been a Scala fan since I discovered it in 2006 (I was a functional programmer before), and even if I barely used it at work (barely is better than not at all, right?), I know it pretty well thanks to my pet projects. I'm still polishing the slides. I've already covered a lot of ground and when I think about all the stuff I decided to let aside (to keep the audience mentally sane), there's clearly a lot to say about Scala. But that's not a reason to be afraid: going back on all the languages features, I couldn't help but think how great the language is, and that I'd like to use it for daily work. I hope I will soon (what's great with OSGi is that it can make polyglot programming on the JVM transparent!).

Oh yes, since I'm a Scala fan I'm also proposing a standard talk on E4 and Scala, and what we get from mixing them.

OK, so this was pretty dense, but I promise my next posts will be more focused and detailed. Until then. ;)

This blog's recipe

Entrée

Ingredients:

• OSGi and modular JVM software
• Eclipse E4 and the Eclipse 4 Application Platform
• The marvelous world of build tools (Maven, SBT, ...)
• Functional programming languages in general and Scala in particular
• Web technologies such as XMPP, HTML5, Semantic Web, etc

Main course

Ingredients:

• Software architecture, design patterns, component-based design...
• Distributed source control and distributed development, community development
• Computer science applied to software engineering

Dessert

Ingredients:

• Free Software advocacy, rants and musings
• Random technological or pseudo philosophical talk

I hope you enjoy your meal here.

Update: Woops. I did not expect this particular post to end up on Planet Eclipse. I guess I should start with, "Hello, world. I play with Eclipse E4 and I'll be posting more soon. Stay tuned".