Having worked on quite a few Eclipse plugin-based projects now, including some very large scale applications, I have developed a healthy love/hate relationship with OSGi. It's great when it works, but my experience has been that when things go wrong, OSGi does a dismal job of telling you what and why. "The class was not found" when the class is most definitely in the same plugin it's always been in, is a favorite; if the error would be a heck of a lot easier to find if you were told which plugin was trying to find the class. Or sometimes simply not loading a plugin, often for indeterminate reasons related to versioning, but without any way of finding out why.
So my question is, why do you think the error reporting is so bad? Is it a problem essential to the architecture, or just a nonoptimal implementation? Will it ever get better?
Great question, Ernst. I certainly have been through this kind of frustration in the past.
First off, bear in mind that OSGi per se is not the culprit here. It will depend entirely on which implementation you are using. From your question, and given our book is about the Equinox implementation, I'll assume that.
With regard to the book, we do have a decent size section on troubleshooting, including the classic ClassNotFoundException. But in my personal experience, these kinds of problems can be mitigated by holding to a few core practices:
1. Use DeclarativeServices. If you're coding to OSGi APIs right in your application code, you're doing it wrong. Isolating the bundle lifecycle issues to DS helps a lot.
2. Always use equinox.ds.print=true. It will provide more information when erros do occur.
3. Try to work in small increments. If you try to get a massive bundle ecosystem up in one big bang, the troubles will be too tricky to diagnose. Start small, and grow your implementation a bit at a time, and when there are problems, you'll understand better where to look.
If you are using Eclipse PDE to do your development then there are a whole host of tools available to generate and validate your dependencies. These should dramatically reduce the number of CNF exceptions. The book outlines a number of workflows in this area.