Additionally, this mode is experimental for now and likely to have serious bugs or limitations that could block usage in production environments.

If you rely on these kinds of features in the NetBeans Platform and want the best support, you are encouraged to continue to run the Platform in the traditional mode.

If you simply want to use a few existing OSGi bundles in your Platform-based application without repackaging them, this is already supported as of NetBeans 6.9: OSGiAndNetBeans. Just include these bundles in your application's cluster path (an import tool is available in the module suite GUI for this purpose); Apache Felix will automatically start inside the NetBeans Platform runtime and load those bundles. It is also possible to use the NetBeans module project type to build OSGi bundles from source if your needs are very basic.

What This Is

If, on the other hand, your application is essentially built on OSGi, you already have an OSGi-compliant container you are happy with, you have OSGi-oriented development tools (whether based in the NetBeans IDE or not), and you simply want to take advantage of pieces of the NetBeans Platform in your application, then this alternate mode may be useful.

A small tool (currently available as an Ant task) accepts some NetBeans modules as input - normally a collection of clusters (directories containing modules/*.jar) - and as output produces a collection of OSGi bundles. The module JARs are mostly untouched, the differences being that

Extra files associated with the module, including Class-Path extensions, are packaged inside the bundle.

(Any OSGi bundles found in the input are copied unmodified to the output.)

The bundles thus processed should include org.netbeans.core.osgi (part of the NetBeans Platform in 6.9+) and its transitive dependencies; this contains runtime support that other modules will rely on. You can then load these bundles inside a compliant OSGi container (currently tested on Apache Felix), and they should function more or less as the original NetBeans modules did; see below for details, but as one example, FileUtil.getConfigRoot() will load a "system file system" composed of module XML layers.

These basic services should be enough to run most NetBeans Platform modules that you might want to pick up in your application. Infrastructure such as modular class loading, startup sequence, logging, updates and deployment, etc. are assumed to be handled by your OSGi container or associated software - NetBeans code is not involved.

As a convenience, from a NetBeans module suite project you can run a single Ant target to create bundles for all modules present either as binaries in the cluster path (often just the NetBeans platform cluster) or as sources in the suite itself. There is also a target to start Apache Felix with bundle autodeploy set to this directory. This feature is mainly intended as a way to quickly demonstrate that some modules can be run in pure OSGi mode; a realistic development scenario would probably involve converting a NetBeans release into OSGi format once and then using OSGi-oriented tools for all further development.

The NetBeans main window GUI will be run if you include org.netbeans.core.windows. Standard L&F customizations are applied and a splash screen is shown with your branding.

Modules are loaded in dependency order, taking into account also OpenIDE-Module-Provides, OpenIDE-Module-Requires, and OpenIDE-Module-Needs. OS-specific modules such as applemenu are loaded only when appropriate.

What Does Not Yet Work

This list does not include fundamental limitations as listed above, such as the lack of support for CLI options. The following are items which could be expected to be fixed to make for a production-quality feature.

There is no support for running the module -> bundle conversion using Maven.

Bundled JNI libraries are not packaged so that OSGi can find them. (JNA should not be affected.)

Some special file attributes of the system filesystem are not supported:

removeWritables to revert modifications to $cachedir/config

class:* to inspect type of newvalue/methodvalue

layers to determine owning module

What Probably Cannot be Made to Work

Friend and implementation dependencies should be translated somehow using import constraints. Currently such APIs are just exposed as public. It is not clear it is even possible to fix this issue, since Import-Package does not support packages split across modules, which are very commonplace in the NetBeans APIs; Require-Bundle is needed to support these cases, but that does not support either the constraints needed for friend dependencies, or the importer-controlled package list needed for implementation dependencies.

If Plugin Manager is included in the module set, its GUI will simply be suppressed. The API is still active if other modules try to use it, but attempts to do so will just produce errors since the NB module system cannot be started. Would be nice for an alternate module provider to be injected in OSGi mode which can at least display a read-only list of installed bundles.

Some modules assume that Thread.currentThread().getContextClassLoader() == Lookup.getDefault().lookup(ClassLoader.class), which is always a risky assumption and will not be true in an OSGi environment. (Setting the CCL might adversely affect non-NetBeans bundles.)

Some modules assume that Class.forName(String) will work to load JRE classes even in sun.* or other private packages. This does not work from an OSGi bundle unless the module has used DynamicImport-Package, which the translator does not generate unless it sees a static (non-reflective) reference. The fix is to use ClassLoader.getSystemClassLoader().loadClass(String) instead.

NetBeans code sometimes runs some cleanup processes (e.g. related to finalization) asynchronously; if this happens after/during framework shutdown, Felix throws errors. FELIX-2128 OSGi bundles are forbidden to run any code (even finalizers!) after the bundle has been stopped, but this is very hard to enforce. Equinox is said to be more forgiving.

Branding only works with a clean bundle cache directory. FELIX-2177 (fixed for Felix 3)