Chris Aniszczyk's (zx) diatribe

The Eclipse Foundation is hosting a webinar in a couple weeks on Gemini…

Gemini Project Lead Mike Keith is presenting a webinar on the relationship between Java EE and OSGi and what the Gemini project is doing in this area. He will detail its relationship to the standards and highlight the role it is playing in implementing a next generation of Java EE architectures. He will go over the various components of the project and show how they can be used by applications and tools alike.

If you are interested in OSGi, I recommend registering. I’ll be there.

In Eclipse 3.6 M7, it will be easier to access the OSGi Console within the running Eclipse. The Equinox team added a org.eclipse.osgi.framework.console.ConsoleSession service that you can use to get the input and output to a console session. The PDE team took advantage of this recently by extending the org.eclipse.ui.console.consoleFactories extension point and allowing you to bring up the OSGi console easily…

This was feature was really put in for some members of the Equinox team but thank you to Dave Carver for encouraging me to blog about it so other people would know about.

Looks like some people are exposing OSGi on Lotus Domino servers.

I especially like the part when they mention the benefits of extensibility, easy deployment and leveraging existing OSGi assets. Oh, the mention that they get “better tooling with Eclipse IDE and its first class Java and plugins editors and Java debugger” is a nice touch too. In all seriousness, the more OSGi gets exposed in the significantly large Lotus ecosystem the better.

Yesterday, Martin Lippert, Jeff McAffer and Paul Vanderlei gave a talk on OSGi Best and Worst Practices.

I really enjoyed the talk because between the four of us, we have a unique and pragmatic perspective on OSGi. I come mostly from a tooling OSGi background but have dabbled in runtime. Martin has been working with enterprise clients deploying OSGi technology for a long time. Paul focuses on embedding OSGi in crazy places. Jeff is just wise OSGi sage, helped Eclipse move to OSGi and has just been doing this forever.

We decided to go the presentation zen approach and it seemed to be received well by the audience. We were a little hesitant at first because deeply technical audiences don’t seem to take the zen style well from my experience, but looks like people enjoyed it. I guess anytime you characterize Peter Kriens as tinkerbell sprinkling OSGi dust everywhere people get a kick out of it.

On top of that, we had a good debate on Require-Bundle versus Import-Package.

I think the devil in the picture above looks more productive, right ?

In the end, I hope you benefited from our experiences and learned something along the way.

Tomorrow as part of OSGi DevCon 2010… Simon Archer, Jeff McAffer, Paul Vanderlei and I will be giving an awesome OSGi tutorial. The tutorial will take you through developing a fully functional OSGi-based application based on the famous Toast example from the OSGi and Equinox book.

We’ll cover the key elements of OSGi and creating OSGi-based systems with principles and practices that are applicable in a wide range of application domains and execution scenarios. A lot of time and effort went into the book and Toast example. In my opinion, the Toast example is the best OSGi example out there and you’ll benefit from learning it.

Why should you come to our OSGi tutorial? Well, you’ll have the eyes and ears of four guys who have been doing OSGi for many years. On top of that, you’ll get to hear us make some controversial statements like when programming OSGi, don’t use OSGi. Oh, and you’ll hear Jeff talk about how modularity is the lubrication of collaboration.

When I came home last night, I was delighted to find a package (because I’m a fan of gifts).

What was in the package? A brand spanking new copy of the Equinox OSGi book.

In my biased opinion, this is best OSGi book on the market. I’ve had the honor to see the book evolve while it was written. Through that experience, the OSGi tooling at Eclipse (PDE) improved significantly. The authors were kind enough to nag inform me when things didn’t work the way they desired and I did my best to fix everything.

Why is this the best OSGi book on the market? First off, the authors know their stuff and have been working with OSGi before it was cool. Second, the book comes with one of the best example OSGi applications I’ve seen. Third, kind words are said about me in the Acknowledgments section

The only downside, my last name was spelled wrong in the Acknowledgments section (will be fixed in second printing).

So what are you waiting for, grab the book and play with the Toast example.

If you want hands on training from the authors of the book and me, please attend our tutorial at EclipseCon! It’s not too late to register!

How exciting to finally have the Equinox and OSGi book done (see the book review from DZone). In the Eclipse community, many people complain about the lack of documentation and reference material, well that should be less of a problem given the book and excellent Toast example.

You can download the first chapter for free (and the 6th chapter).

I may be a bit biased (see the kind words about me in the Acknowledgments section of the book), but I believe this is the most comprehensive book on OSGi out there. The authors have many years of practical OSGi experience, from the days to when OSGi wasn’t cool yet (SMF) to when it became the basis of Eclipse. On top of that, I think the best thing that comes out of this book is the open sourced Toast example. Expect to see a lot us within the Eclipse community use this example when we talk about OSGi, Equinox and EclipseRT.

So what are you waiting for, go buy the book and learn about OSGi.

Over the past few weeks, I’ve helped plan and organize a panel at EclipseCon called The Future of Application Servers.

In the past few years, application servers have been evolving rapidly and with the advent of OSGi leaking into application servers, we are seeing modularity being introduced to the typical application developer. The main goals of the panel is to explore what application servers may look like in the future and how application server programming models may evolve. The panel will feature leaders from their respective application server communities… from Eclipse Virgo (dmServer) to IBM Websphere:

• Glyn Normington (VMWare/SpringSource)
• Graham Charters (IBM)
• Rich Sharples (JBoss/Red Hat)
• Mike Lehmann (Oracle)
• Greg Wilkins (webtide)

John R. Rymer from Forrester Research will be moderating the panel.

If you’re interested in the future of application servers, swing by and attend EclipseCon!

Over the holidays, I’ve been having a blast with the BUG from Bug Labs.

What is the BUG you ask? Well, it’s a bit hard to explain but on the high level think of it as programmable LEGOs for adults. It’s essentially a collection of electronic modules you can easily snap together and program to make any device or gadget you want. There are many modules available for the BUG…

Using these modules you can build any device you want. Once you have built creation, you can start developing applications for that particular device. For example, I can have the BUGlocate (GPS) and BUGmotion (accelerometer) modules and develop an application that takes a picture between a certain time and tweets the photo.

In my opinion, the coolest thing about the BUG is that it’s open source and enables modularity via OSGi. Under the covers, it is using the Concierge OSGi framework implementation due to size constraints.

Since I’m a hardened OSGi guy, I found developing applications for the BUG really easy. You interact with each of the modules and other applications via OSGi services. For example, the BUGmotion module exposes a com.buglabs.bug.module.motion.pub.IMotionSubject service which you can use to get information about motion events.

In terms of tooling, you’ll be right at home with the Eclipse-based Dragonfly SDK (if you’re an Eclipse person).

The SDK makes it pretty easy to launch, test, deploy and find applications. If you’re familiar with Eclipse and Java development, it should be really easy to get started. If you’re familiar with OSGi development in Eclipse, you’ll feel like you’re right at home. They also use some aspects of the Plug-in Development Environment (PDE) from Eclipse to make your life easier (although not as much as I’d like them too). On top of the tooling, the BUG also has an “app store” (called BUGNet) for all of its applications. It’s very easy to browse for applications and have the source downloaded into your SDK.

The ease of browsing and downloading BUG applications makes me jealous as an Eclipse user.

On the whole, I’m very pleased with the BUG. The BUG has changed the way I think about hardware and how it relates to modularity. Furthermore, any company who’s mission is to advance modularity by making it fun and allowing you to build cool devices get kudos from me.

On a side note, given the set of BUG modules, anyone have interesting ideas for an application to develop ? My current thinking is something that involves the motion module, the camera module, my refrigerator, twitter and late night snacking.

I don’t know if it’s just the last sprint before the end of the year for people, but there’s been a decent amount of buzz around software versioning lately. Maybe people (like Mirko Jahn) are just so frustrated with the status quo around versioning.

In the first case, the OSGi community has been blogging about the importance of semantic versioning in regards to the blah approach taken by the Jigsaw project. I find that Peter Kriens wrote an eloquent post about the importance of versioning in module systems like OSGi, especially when it comes to the semantics. In response to JSR 294′s versioning policy (vaguely Debian-like strings), Alex Blewitt has written a funny “JSR294 Fantasy Version Series” featuring a Linux and Roman Numeral versioning scheme. I highly recommend reading Alex’s blog series if you’re in need of a laugh.

I also learned today that the Groovy project is going through a modularization stage since the main Groovy JAR is now over 4MB and there’s a desire to break things apart (I wonder what monsters lurk under that big JAR). I hope the Groovy team considers a hard look at OSGi and also the importance of semantic versioning for its modules. Since it seems Groovy uses Maven as part of its build infrastructure, it should be easy to adopt OSGi with the upcoming Maven3 release and Tycho.

Ok, what about modularity and versioning outside the Java world? Well, to my surprise and excitement, there’s some activity in the Javascript space via the CommonJS group. The purpose of the CommonJS group is to build a JavaScript ecosystem for web servers, desktop and command line apps. As part of this effort, the group is developing a module and package system. While I still think they are a bit crazy, I’m happy to see that they are standardizing their versioning scheme (called SemVer) to include semantics.

If you look deeper into CommonJS and their module system, a lot of the metadata that they are defining for their modules map quite nicely to OSGi. Is it time that OSGi considers stepping out of the comfortable Java space and embrace modularity for other languages like JavaScript? There’s a lot of lessons the OSGi community can give to the modularity newcomers.

Has anyone seen anything else good when it comes to modularity and software versioning?

On a side note, sometimes I wonder if we need something like the Agile Manifesto but for Semantic Verisoning. I’d call it a Semantic Versioning Manifesto where people could sign it and support it. What do people think?