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.

It would be great to hear from the greater Eclipse community about this topic.

For those who don’t like all this talk about tiny execution environments, check out BJ Hargrave’s EclipseCon submission about OSGi Framework 2.0… J2SE-1.5 at the framework level… sounds fun!

I was pretty sure Equinox was “enterprise ready” already, but I learned that “enterprise ready” in SAP terms is meaning to support something like 50,000 bundles running… sounds like fun! It was also very encouraging to see SAP adopt open-source technology where it makes sense and even commit resources to the open-source projects that are important to them. The move from simply a consumer to a producer of open-source technology is a huge one. For large companies like SAP, this isn’t always easy due to corporate culture.

It was also interesting to see that SAP was very methodical in their choice of OSGi framework. During the members meeting, they showed their test results pitting the various frameworks against each other:

It’s cool to see Equinox come on top most of the time. I’m sure with SAP’s involvement in the future, Equinox will shine even more.

• Security Enhancements
• BundleTracker (kind of like ServiceTracker but for bundles!)
• Bundle-License header (finally, but something more to tool…)
• Service Registry Hooks
• A common CLI for OSGi! (finally!)
• Declarative Services Updates
• Transactions in OSGi
• Distributed OSGi (smells unnecessarily complicated but cool)
• Common Component Model (Spring-DM)

It looks like there’s a lot of cool things going into 4.2… especially things like Distributed OSGi which can have a lot of downstream ramifications on people who use OSGi and want to use it in a distributed fashion.

I think we can do better than this and try to mimick the concept we have with internal packages and x-friends. For example, imagine an extension point you wanted to define to be used just but your plug-ins for now… it’s useful for you internally but not ready to open to the public yet. In PDE, we could allow you to define an extension point as internal and maybe give it some “friends” that wouldn’t be flagged as discouraged access to the extension point.

What does the community think? Is this something valuable for people?

• Initial Provisioning (CVS) (note: not related to p2)
• IO Connector (CVS)
• Wire Admin (CVS) (note: nothing to do with wiring packages)
• Declarative Services (CVS)

This is good news because the old Declarative Services implementation in Equinox sucked due to concurrency issues and Equinox didn’t have any of the other mentioned implementations. It’s good to see more services out there for people to take advantage of… especially when they are in the OSGi specifications.

With that said, anyone want to contribute Declarative Services tooling to PDE? New contributors don’t be scared… I have room for you in the PDE Incubator

Not so bad eh? Well, when talking to Equinox Framework extradonaire, Tom Watson, he was a bit confused by the icons. He pointed me to a picture that Peter Kriens uses to describe OSGi services apparently:

That’s cute… I can see that Peter was trying to describe that only one bundle can register a specific service (pointy side of triangle) and multiple bundles can bind to it (flat side of the triangle). However, this doesn’t really help me in creating an icon that normal people would understand… also… why a triangle? So I tried to hack something up quickly in a budget paint program:

Ok, I kept the triangle… hypothetically put an ‘S’ on it to represent service… than I put arrows on the top and bottom of the triangle to represent “importing” and “exporting” services. Nope, I’m not satisfied with this crap either. Actually, when I think about it… visualizing services is as confusing as driving in Boston:

How does everyone out there picture OSGi services in their heads?

There was an issue recently where the RCP stack had trouble running in strict mode. There were a few naughty RCP-related extensions that were referencing internal classes in other RCP plug-ins. These extensions are frustratingly hard to find if there’s no tooling. For example, when launching the RCP ‘Hello World’ example in strict mode, you come across this exception:

You think to your self, well pffft, I can fix that, I’ll just x-friend that package to my plug-in and be done with:

Then you go to launch the RCP ‘Hello World’ example and you get this frustrating exception again:

This is when the game of finding the offenders doesn’t become fun anymore. Actually, the feeling is very similar to when that stupid dog was laughing at you in Duck Hunt because you couldn’t shoot all the ducks:

However, never fear, PDE completed an enhancement that will make it easier for you to find these offenders:

The solution to this problem is to use x-friends or as a better best practice, don’t refer to internal classes outside your plug-in in your extensions as this is brittle.

Happy hunting.

It’s funny that I agonize over things like icons when probably only a few people in the Eclipse community really care about pushing pixels. In the end, I lost my battle with overlays so another redesign of the schema editor icons will happen in the future to make them more overlay friendly:

I also had fun trying to come up with icons representing OSGi services but I’m going to save that rant for tomorrow.

Another item coming from PDE is a filterable launch configuration:

This is incredibly useful if you want to filter for a set of plug-ins and either enable or disable them. For example, say you wanted no org.apache* plug-ins in your launch config, simply filter for them and click ‘Deselect All’ (it’s filter-sensitive now). No more going through and checking things individually! Everyone can thank Ian Bull for his persistence in getting this enhancement in.

The other thing I’m looking forward to in the upcoming I-build is improved colored label support. Look for PDE to adopt this in things like the ‘Open Plug-in Artifact’ dialog and other places that make sense. If you’re interested in test driving this functionality, look for a class called StyledCellLabelProvider in the 3.4M6 release.

Oh, and JDT Core released some crazy changes to support external class folders. I plan on looking at this support in depth after my vacation to see if we can close an old outstanding issue in PDE.

That’s all that comes across my mind for now