There is one point in the blog the I don’t like at all. It’s yet again I hear the myth about automatically generating OSGi bundles from 3rd party libraries and how successful it is used in the SpringSource bundle repository. Folks, it might work for one 3rd party library but it will never work  in an automated way for all 3rd party libraries. There are just too many issues around OSGi-fying 3rd party libs which need to be addressed carefully. If the library deals with class loading you might be out of luck no matter how great your generated manifests look like. You need to modify your source code and/or patch the 3rd party library to make it work correctly. Even better, sometimes there are multiple ways to convert a 3rd party library into an OSGi bundle. A stubborn one-to-one conversion process cannot incorporate that. It may depend on your requirements and preferences.

The process is not finished with generating manifests. Be aware that this can cause broken bundles. Those issues are fixable. But this example shows that every library requires careful attention.

Sorry folks, with all due respect to model driven software engineering, but that’s totally non-sense. It’s all about developer productivity. The first object is always the hardest. But if you follow the right approach and build good APIs and use the right tools than it’s just a matter of minutes for every other domain object.

Don’t get me wrong. I also use EMF and I love it. But some statements are just plain wrong.

A cursory look at the architectures of many of the top level projects (WTP, STP, TPTP, BIRT etc.) shows the lack of intra-project cooperation is resulting in frameworks that simply don’t integrate with one another in they ways we all want them to.

Honestly, I partly agree with John but more from a usability point of view. Ok, that’s another topic. But I think we have to remember that all these projects are very young projects compared to the Eclipse top level project itself. You can’t expect to get everything done in release 1.0, 1.5 or even 2.0. AFAIK the first goal was to successfully establish the projects on Eclipse.org and to create a vital user, developer and adopter community. With Callisto I’m expecting this goal marked as fixed.

I also agree that one of the next goals should be concentrating on areas where the projects can create more interoperability. But again, I have to remind that work on this topic has already started in the past. It’s is an ongoing long term goal that can’t just be solver over night or with the next release. For example, the common navigator framework and the tabbed properties view are two good solutions that were contributed to Eclipse as part of the initial WTP contribution and are now integrated into Eclipse 3.2.

On the other side, there are indeed examples of projects creating their own solutions to a very common problem that is better solved at a platform level. I accidentally came across such an issue on the weekend when I was talking to a guy on IRC. He just asked a question about a problem registering selection listeners to workbench parts. Well, I’m a curious guy and I was wondering why someone is watching part activation and registering selection listeners to every single workbench part when there is the workbench’s selection service. So I just asked him and we had a very interesting talk. During this conversation it came out that one Eclipse.org project was trying to create there own data binding framework. Well, that’s crazy and definitely not along the line of Eclipse.

But how to avoid this in the future?

In my opinion it’s all about communication, openness and transparency. This is the great advantage of open source development. But it can only be successful if it’s practiced by all involved parties. The issue above just turned out to be caused by a lack of openness and communication. They started developing their own data binding framework because they didn’t know about the JFace data binding framework. You now may ask why is this a problem of openness and communication? Let me explain.

Openness is not only about opening your software and your processes to a community. It’s also about opening yourself and your mind to the input from the community. The same goes for communication. Communication is not only about starting telling everybody what you are going to do but also about starting listening to the community what they do and what’s going on there.

Referring back to the post of John, he asks who is responsible for avoiding miss-interoperability at Eclipse. I think in the example above it’s hard to blame anybody. The project is really young and I bet due to the lack of communication the PMC didn’t know about this. I also don’t think that you ever can blame somebody specific for such issues. It’s the community including committers, leads, PMC members, Eclipse.org member companies and councils that has to demonstrate and practice their openness, transparency and communication skills.