jebailey's blog

I've never ran across a project that screamed at me so loudly to be put into an OSGi framework.

There's multiple stages to an application that's OSGi based. The lowest level of design is just updating your jar files so that the implement the necessary bundle information. This is pretty straightforward and there are ant tasks that will do this for you, using the bndtools.jar and this would provide a plugin framework OOTB

The second level, and where it gets interesting is the conversion of the application into a services framework. Being able to implement a level of separation of concern is where OSGi shines.

My general thought process is that if I see something that I think I can be improved, just don't complain about it, but offer a suggestion.

So my thoughts turned to the documentation that's available for JNode. What could we do to improve the documentation, and what do I mean when I say improve it. Documentation is difficult, and can be boring if you don't have the mindset for it. It's also extremely important for new and old users to have a robust level of documentation to support the project.

One of the obvious solutions is a wiki, however wiki's require monitoring and administration and servers. Another solution, which JNode is currently doing, is centralizing the documentation on a CMS but limiting the rights of the people who can modify it. This can work pretty well but can suffer for the same reason that wiki's do which is the lack of man power in a slow moving, large project.

My recommendation is to push the core documentation into the source code, as a project in it's own right.
Which provides the following benefits

• Documentation is now available offline
• There is a history of the documentation