OSGi vs. NetBeans module system

I don't have very much practical experience regarding OSGi besides running and testing a few sample applications. But I've work some time with the NetBeans rich client platform which provides an own module systems (which was not based on OSGi that time). Do you have any experience how this can be compared to the solution with OSGi/Spring, i.e. in which way they are similar or distinct from each other?

Marco Ehrentreich wrote:I don't have very much practical experience regarding OSGi besides running and testing a few sample applications. But I've work some time with the NetBeans rich client platform which provides an own module systems (which was not based on OSGi that time). Do you have any experience how this can be compared to the solution with OSGi/Spring, i.e. in which way they are similar or distinct from each other?

It seems that you and I have had opposite experiences with these module systems. I've had no experience with NetBeans' module system, so I can't speak to how it compares with OSGi. Sorry.

Maybe I can try to explain the basic ideas behind the NetBeans module system...

- NetBeans allows (partly) to insert or remove module bundles at runtime.
- It automatically manages dependencies and takes care to avoid circular dependencies.
- The current version seems to allow modules to get loaded only on demand.
- NetBeans allows meta data for modules like a version number, description...
- A module can be almost anything, including resources like images etc.
- NetBeans allows to distinguish between service APIs and service implementations (which can be in different modules).

There are probably more things to it, but i guess these are the most important ideas behind the NetBeans module system.

Marco

Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335

5

posted Jul 20, 2009 23:37:56

0

Marco Ehrentreich wrote: - NetBeans allows (partly) to insert or remove module bundles at runtime.
- It automatically manages dependencies and takes care to avoid circular dependencies.
- The current version seems to allow modules to get loaded only on demand.
- NetBeans allows meta data for modules like a version number, description...
- A module can be almost anything, including resources like images etc.
- NetBeans allows to distinguish between service APIs and service implementations (which can be in different modules).

Sounds quite similar to OSGi. Let me create my own list of OSGi capabilities:
- OSGi allows bundles (what they call modules in OSGi...just JAR files with special info in the manifest) to be installed, uninstalled, stopped, started, or replaced at runtime while the app is running.
- Dependencies are automatically handled at the package level. A bundle may declare that it exports one or more packages (all others will be private to that bundle by default) and another bundle may declare that it imports those packages. If there's more than one version of a given package available, the bundle can declare which version it uses.
- OSGi leverages the META-INF/MANIFEST.MF file found in every JAR file for its metadata. That metadata may include, among other things, version numbers, descriptions, packages imported/exported, etc.
- Modules in OSGi are JAR files. An image (for instance) can't be a module. But a bundle may contain an image that is made available to other bundles.
- Just like NetBeans, service interfaces and implementations are distinct concepts and can be in different bundles.

So, without knowing any more about NetBeans, I can say that OSGi and NetBeans modules share a lot of commonality. Where do they differ? I don't know...yet. Which is better? I'm going to avoid answering that question.

Without knowing any more about OSGi I can confirm that the two are VERY similar

Everything you wrote reads like a description of NetBeans. Even the concept with the manifest files works the same way in NetBeans. So I'd say they have almost everything in common. So it's no wonder I just found this article in the NetBeans wiki collecting ideas to align the NetBeans module system and OSGi even closer.

Marco

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com