...

• Include-Bundle - A comma-separate list of bundle URLs.

The constituent bundles of a composite bundle are isolated from the other bundles in the parent framework. In other words, they can only see their sibling constituent bundles and bundles in the parent framework can only see the composite bundle, not its constituent bundles.

To simplify mapping a composite bundle's exported packages to its constituent bundles, this proposal introduces a new from directive for Export-Package, which is used to specify the symbolic name of the providing bundle. Consider the following composite declaration:

...

Since composite bundles are implemented as virtual bundles, access to their content and portions of their lifecycle are controlled by an external manager. As a result, their lifecycle handling is slightly different from normal bundles. This section describes various composite lifecycle management issues for simple composite bundles.

4.1.2.1 Composite manager

The composite manager results from the use of virtual bundles . The composite manager and is largely responsible for actually realizing the capabilities embodied in the composite declaration headersdescription. This means it is the composite manager's responsibility to:

• Manage a composite bundle's constituent bundles.
• Provide constituent bundles access to imported packages , required bundles, and imported services.
• Provide the parent framework access to exported packages , provided bundles, and exported services.
• Manage the overall lifecycle of composite bundles.

The precise approach the composite manager uses to accomplish these responsibilities is not specified, but one potential approach is for the composite manager to create different a separate framework instance for each composite bundle.

4.1.2.2 Installing composites

If an "install hook" is introduced in the virtual bundle proposal, then the composite manager can use it to seamlessly install composite bundles via the BundleContext.installBundle() method , like any a 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 from the perspective of the parent framework.

4.1.2.3 Resolving composites

The composite bundle's wires for its required imported packages and bundles are injected into the composite's virtual module by the framework, like for all virtual bundles, which the . The composite manager can use uses these wires for delegation purposes out to the parent framework for the constituent bundles. If a composite bundle 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

NOTE: Resolving a composite bundle could actually be combined with some sort of verification step, where the manager verifies whether or not the composite bundle can provide what it says it can provide. It is not clear if this needs to be specified, since such verification does not happen for normal bundles. In other words, it is a reasonable approach to just trust the metadata.

4.1.2.4 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 services imported services from the parent framework 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 these 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. For simplicity, it is probably better to effectively make it a no-op.

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

NOTE: Since this proposal does not propose an API to expose the constituent bundles, individual lifecycle manipulation of the constituent bundles is not expected. To keep things simple, constituent bundles are either active or not based on the state of their composite bundle. If more fine-grained control is required it would be possible. Starting and stopping individual constituent bundles would offer no real issue, although allowing them to be refreshed or uninstalled might cause the composite manager to force the outer composite bundle to refresh if the export signature is impacted.

4.1.2.5 Refreshing a composite

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

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

NOTE 2: Refreshing a provided bundle should likely be a no-op internal to the composite bundle, although it will cause a refresh of dependent bundles in the parent framework. Likewise, if the composite bundle depends on another bundle being refreshed in the parent framework, then it will be refreshed too.

4.1.2.6 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 bundle is uninstalled, the composite manager must immediately refresh it to perform proper clean up, since it will not be able to get a later lifecycle callback when the bundle is eventually refreshed.

NOTE: This could be improved with a VirtualModule.dispose() method, indicating that which would be invoked by the framework is really to indicate it done with the virtual module.

...

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.

4

...

.2

...

Lifecycle control flows down, not up

4.2 Extended composite model

4.2.1 Extended composite description

...

4.2.2 Extended composite lifecycle management

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. For simplicity, it is probably better to effectively make it a no-op.

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 1: Another approach for provided bundles is to uninstall and refresh them.

NOTE 2: Refreshing a provided bundle should likely be a no-op internal to the composite bundle, although it will cause a refresh of dependent bundles in the parent framework.

4.1.2.8 Lifecycle flow

Lifecycle control flows down, not up

5. Open issues

5.1 Rich wiring information

...