Attention: This is a draft

The most challenging part of the OSGi specifications in the context of a native implementation is the Module Layer.

• In Java, the OSGi Module Layer is about visibility of packages and the ability to enable code sharing between bundles in a controlled way.
• Question: Allow code sharing in Native OSGi (which means having link-time dependencies between bundles)? Yes! Although it will be not advised, code sharing will be allowed. The nOSGi wiring technique seems promising, have to investigate the cross-platform feasibility.
• A native shared library will be the (rough) equivalent to a Java package

Some bundle manifest headers

• Bundle-SymbolicName
• Bundle-Name
• Bundle-Version
• Import-Library
• Export-Library
• Bundle-RequiredExecutionEnvironment (a list of needed system libraries)

This list is by no means complete.

We need to determine if we need a manifest header which lists all shared libraries (topologically sorted according to their dependencies) which have to be loaded during bundle start-up. Maybe the dependencies can be determined at runtime with platform specific tools. We need that information to be able to load the shared libraries within the framework such that we do not have to fiddle with environment variables and RPATH entries.