Note this roadmap is still a draft.
Date: TBD (juli/aug 2017?)
For different reasons it could be interesting to support running bundles from a single executable. Primarily security, but also startup performance.
To start this can be achieved by creating static version of the celix provided bundles. These static bundles should have unique symbols, e.g shell_bundleActivator_create instead of a “normal” bundleActivator_create. The normal activator functions should then only be used (using a define or separated source file) when building a shared library bundle. A additional property (e.g. “cosgi.auto.static.start=shell, shell_tui”) can be used to specify which symbol prefixes to use.
Note that if this is implemented it would also be a good moment to add a compile option / launcher option to disable dynamic loading of libraries. This way shared library based bundles can be used during development, but for production a static executable with no capability to add bundles runtime could be used if preferable.
Date: TBD (Jan 2018)
Note a short comming is that there is still no good support for export and import libraries between bundles. For Linux dlmopen is a solution, but for a more broader UNIX support a more “creative” solution is needed (e.g. Just in time replacing the SONAME and NEEDED values in the respective shared libraries)
The dependency manager offers declarative API for working with services and is arguable more easier to use than the official OSGi Api. Extend the DM so that in can be used for virtually any bundle without directly using the bundle context, bundle, module, service ref, service registration, etc API. This provided a much smaller API providing almost the same functionality.
This means:
listener_hook_service service, but maybe a more abstracted way.Apache Celix is a framework for service oriented programming, this should also include for interacting with the framework itself. Create framework services for:
Because the dependency manager is actual the preferred way to write bundles, this should be support like “normal” activators" directly from the framework without using a static library.
Refactor Celix bundles (shell, shell_tuu, RSA, etc) to use the dependency manager instead of a “vanilla” bundle activator. The dependency manager should be the preferred way to handle services. Also instead of directly using the API from bundle_context, bundle, module, etc the framework services should be used.
Create a descriptor generator which can parse type and service headers. This can be relatively easy achieved by (e.g.) using the libclang library. Also extend the CMake add_bundle command and create a CMake bundle_add_descriptors command to be able to add the descriptors to the bundle
When available dfi descriptors can be used in Celix to validate if service are compatible and in case of the provided service having more functions than the consumer needs, create a (cast to) a compatible consumer version.
Date: TBD (aug 2018)
When all Celix provided bundles are using the dependency manager and framework services support for the “vanilla” bundle activator can be dropped. Also a lot internals can be refactored because the public API should have shrunk quite a bit; This should lead to smaller code base -> less complex, easier to maintain and a smaller footprint.
Celix currently has some nested lock. It would be preferable to remove these, but this is difficult because they are used to sync events which react on registering/unregistering services. Specially when a unregister/register event leads to other services being registered/unregisterd. One way to deal with this sync problem is to remove it by adding a single thread which handle al interaction between bundles and the service registry.