NetBeans and OSGi

NetBeans Module System and OSGi are kind of similar. They provide a way how to write modular systems, they encode their metadata in MANIFEST.MF, etc. This page has been create to host the "alignment" effort, e.g. ideas, plans and other work that could lead to crossing the gap and making the system even more similar, potentially replaceable.

All of this started when Richard S. Hall told me that he is a NetBeans IDE user, but the fact that NetBeans cannot run inside of Felix makes him look bad inside his own community. He said that he would like to try to port NetBeans and I thought, ok, that is not bad idea. If anyone wants to try it, we (I mean Sun employees working on NetBeans) are not going to stop you. In fact we are even able to give you some advices. This page contains the advices we gathered so far.

What NetBeans need to know about its modules:

• Access to all resources of a module.
  • Achievable using Bundle entry-related methods (e.g., getEntry(), getEntryPaths(), and findEntry()).
• Ability to have a "super" class loader that can load classes from all modules.
  • Achievable with a custom class loader that wraps all available bundles and calls Bundle.loadClass() to delegate to the bundles.
• Generic provide/require tokens.
  • Achievable by exposing generic provide/require mechanisms of Felix and/or Equinox, but this would not be part of the OSGi R4.1 spec, but could be raised as an issue for R5 since it was discussed for R4.

Can NetBeans run inside OSGi container?

Can Felix recognize modules in the current NetBeans locations. E.g. platformX/modules/ or ideY/modules, etc. If that would be doable, then good, we do not need to do any changes to the layout.

It depends on what you mean to "recognize" them, but if I understand what you mean, then I think we have a couple of options:

• We could create a sort of "launcher" bundle that probes the local machine (or user home) for installed NetBeans systems and could then launch a discovered installation by automatically installing the modules discovered in the locations you mention.

• Or we could create a custom launcher for Felix that can discover a NetBeans installation and then automatically load the modules from the above locations into the OSGi framework.

Last thing related to this is classpath. Currently NetBeans contain three JARs that are on classpath (platform/lib/*.jar) and two that are treated in a special way (platform/core/*.jar). I guess that in your proposal, you would like to treat these as modules. Felix would be on classpath, all NetBeans JARs would be loaded dynamically completely under control of Felix.

It is not 100% necessary to have everything in a module, but that is probably better. The OSGi framework allows you to put stuff on the class path too. There are two ways for modules to access classes on the class path:

• The class path packages can be exported by the OSGi framework, in which case modules that use them must explicitly import the corresponding packages.
• The class path packages can also be made available to all modules implicitly (i.e., they don't have to import the associated packages), by a mechanism we call boot class path delegation.

So, it is probably better if everything is in a module, but it is not strictly required. Ok, let's try to make everything a module/bundle.

Implementation dependencies

Can OSGi mimic implementation dependencies? E.g. bundle dependency when the other bundle sees even non-exported packages from the other one?

Inject OSGi metadata into manifest?

To be clear, my vision is one where we create a "NetBeans-like module layer" on top of OSGi, so that NetBeans modules are not impacted in general.

Do you want to write a tool that will enhance NetBeans manifests to OSGi understandable ones?

As for the tool, the Ant task to patch is here: JarWithModuleAttributes JarWithModuleAttributesTest

Moving Forward

• mailing list - TODO
• branch in netbeans.org CVS - TODO
• sandbox project under different license - TODO