I came across this couple of times before and I always wanted to blog about it. In my daily work life I see many developers which just don’t get Open Source. For example, some discover issues in libraries they use. But they don’t fix them. They don’t even inform the maintainers of a library. Yet others have a great new use-case to address. Again, the library doesn’t support it. Thus, they write a great deal of new code to address their issue and eventually run into new ones (for example, see this thread).
But it’s that darn simple!
- Checkout the library from source. You can use a well known tag/branch for this.
- Get in touch with the maintainers and implement your modifications.
- Build and release your modified version until a new official release is available.
Ever wondered why Eclipse (or any Java app) is still pointing to your old Windows profile (eg. after renaming or copying it)? It’s a known JRE bug. They use a Windows registry entry for setting the user.home property.
I just had that upps effect with RSSOwl. All my blogs were gone after removing the old profile dir which I haven’t used for months (I moved out of a Windows domain severel weeks ago).
Who else read RFC 124? It has a really funny title: “A Component Model for OSGi”. Yeah, that really speaks for itself. Just repeat it a few times and let it settle for a while. So, RFC 124 wants to create a component model for a component model. Funny, eh?
But is that really what people need? Maybe I just don’t get it but I thought the real problem was that programming OSGi is too verbose.
Well, I’m certainly not arguing against that. Programming OSGi is verbose. When creating services you need to write additional code to maintain their registrations. When consuming services you need to write additional code to track available services. Last but not least you need some plumbing around. Continue reading OSGi RFC 124