Category Archives: J2EE

J2EE related topics

The myth of OSGi-fying 3rd party libraries

Eclipse, J2EE, Software Engineering, ,

There is a nice SpringSource blog about their plans for building OSGi applications. Actually, it’s more an advertisment for their tool called bundlor which basically has the same purpose as bnd but is implemented in a different way.

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.

Persisting Data

Eclipse, J2EE, Software Engineering

Why do people always want to tell you that persisting a “domain model” is a many month spanning work item if you can’t generate the code?

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.

Isolated solutions

Eclipse, J2EE, Software Engineering

In this post Mike refers (and answers?) to a blog posting from John O’Shea. John is complaining about the architecture and interoperability of several Eclipse top level projects (named WTP, STP, TPTP, BIRT).

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. Continue reading Isolated solutions →