Geertjan's Blog

  • March 18, 2010

Minimum Dependencies for EMF? (Part 1)

Geertjan Wielenga
Product Manager
Two of the most frequently asked questions during NetBeans Platform Certified Trainings are:
  • Can I integrate my OSGi bundles into a NetBeans Platform application?

  • Can I integrate my EMF models into a NetBeans Platform application?

Unequivocally, and for the first time, I can now reply "YES" to both these questions.

OSGi can now exist alongside the NetBeans Platform's runtime container. The key to how all this is possible is below, in Jarda's own (though slightly paraphrased, by me) words:

"I decided to write a bridge. The basic idea is to let the two independent APIs live alongside each other and bridge information between them in a way that allows them to talk to each other.

Thus Netigso [the OSGi/NetBeans solution that is part of NetBeans IDE 6.9], runs two containers in the same Java virtual machine, alongside each other. The first container is the regular NetBeans Platform runtime container and the second container is Felix [or Equinox, via Netbinox] - an OSGi implementation written by Richard Hall. The bridge goes through all the registered JAR files and decides whether they represent an OSGi or NetBeans JAR (unsurpisingly, both systems use JARs as basic packaging units and also store additional information about the JARs in their manifest). Each JAR is then passed to the right container to receive the appropriate runtime environment.

Moreover, each JAR has a shadow - a fake peer registered in the other container - that just sits there and is ready to do the bridging. What kind of bridging? Well, mostly class or resource loading. As soon as there is a NetBeans module that has a module dependency (a.k.a "requires bundle") on some OSGi bundle, the shadow associated with that bundle gets activated. The NetBeans module then delegates all class or resource loading to that bundle. Similarly, if there is a NetBeans module exposing some public packages, any OSGi bundle can import them, which activates the shadow bundle associated with that module. The activation is then intercepted and the alternative bundle's loading mechanism is injected into it, which delegates all resource loading to the NetBeans module.

The beauty of this solution is that it remains fully compatible for both worlds."

For more on the above, see http://wiki.apidesign.org/wiki/Netigso, which is in Jarda's own unique words.

Today, I had my first experience in the actual USEFULNESS of mixing OSGi with the NetBeans runtime container. I took Gunnar's fantastic EMF/NetBeans integration sample and moved it to the tooling environment for Equinox that will be part of NetBeans IDE 6.9. Read about that here.

Right now, the only question I still have is very practical: what is the minimum set of EMF dependencies that I need when using EMF? I mean, in the example I took the entire "eclipse/plugins" folder, which contains over 1000 OSGi bundles. Not a very performant solution and, though the tooling handles everything well, that's not what I should be delivering to my users. I know there are tools for finding what the dependencies of some OSGi bundles are, though I would have thought there'd be a page that simply lists common OSGi bundle combinations, in the form of "if you want to use EMF, you will need the following dependencies", followed by a list of dependencies. Is there such a page or, if not, can someone tell me what the minimum set of dependencies is?

I can see us, assuming we can really get down to a minimum set of EMF dependencies (since the world is not enough!), including EMF in our NetBeans Platform Certified Trainings in the future. In fact, if such a minimum set of EMF dependencies can be identified, consider me a new EMF evangelist because it is, in that case (but only in that case), clearly a great system that NetBeans Platform developers will love to have in their toolkit.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.