...

NOTE: It is not clear if Import-Package should essentially support an "export as" directive where the composite creator explicitly specifies how the imported package gets converted to an export internally or if this should be somehow automatically converted by derived from the eventually actual injected wire. If the latter, then this relates to the rich wiring section in the open issues.

...

The precise approach the composite manager uses to accomplish these responsibilities is not specified.

General lifecycle management

Installing composites

If In general, composite lifecycle management follows that of any virtual bundle, which is not completely fleshed out in all cases. For installation, if an "install hook" is introduced for in the virtual bundle proposal, then the composite manager can use it to seamlessly install composite bundles via the BundleContext.installBundle() method, like any normal bundle. If install hooks are not proposed, then it could provide a simple service for installing composites. A composite is installed with a complete composite description, which forms the manifest of the installed virtual bundle. As such, composite installation is effectively atomic.

For resolving a composite, the wires for the required

Resolving a composite

Refreshing a composite

...

Resolving composites

The composite's wires for its required packages and bundles are injected into the composite's virtual module by the framework, like for all virtual bundles, which the composite manager can use for delegation purposes for the constituent bundles. If a composite is resolved, then it is possible to load classes from it. After a composite is resolved it is also possible to realize any provided bundles in the parent framework.

Starting and stopping composites

Starting a composite bundle starts all internal constituent bundles. Likewise, stopping a composite bundle stops all constituent bundles. Composite bundles do not have user-defined activators, although the composite manager may make use of an activator. For active composites, the composite manager must provide constituent bundles access to imported services and must make exported services available in the parent framework. Conversely, when a composite bundle is no longer active, it must stop providing access to services.

NOTE: For a provided bundle into the parent framework, it is not clear how we should tie its lifecycle to the corresponding constituent bundle and/or whether it should be controllable in the parent framework.

After a composite bundle is stopped, it should remain resolved and continue to provide access to its exported packages and provided bundles.

Refreshing a composite

When refreshing a composite, all constituent bundles are refreshed and the composite bundle returns to the installed state. Any provided bundles in the parent framework will also be refreshed and returned to the installed state and will not be resolvable until the composite is resolved.

NOTE: Another approach for provided bundles is to uninstall and refresh them.

Uninstalling a composite

The normal bundle uninstall operation does not directly mean that a bundle is no longer in use, since it is still possible to load classes from it. Further, the framework provides to additional callbacks or state changes to notify when it is really done with a bundle. As a result, if a composite is uninstalled, the composite manager must immediately refresh it to perform proper clean up.

NOTE: This could be improved with a VirtualModule.dispose() method, indicating that the framework is really done with the virtual module.

Relationship to composite manager lifecycle

Since the composite manager manages all aspects of the composite's content, its active lifetime scopes its managed composites. In other words, if the composite manager is stopped, then it explicitly causes all of its managed composites to refresh and return to the installed state.

Open issues

Rich wiring information

...