...

The overall technical approach is to build a layer on top of the virtual bundle concept (proposed separately) to manage composites composite bundles as a layer above the framework. The specific approach is to forgo This proposal forgoes an API-based approach to support a simple, declarative approach. The technical approach is divided into two halves for supporting a more simplistic composite model and extending this model to support additional scenarios at the expense of making it more complicated.

4.1 Simple composite model

...

.

...

NOTE: The goal is not to completely rule out any API, but to keep things simple until some real-world experience is gained at which point API could potentially be introduced.

4.1 Simple composite model

The simple composite model supports installing groups of bundles as a single composite bundle with the ability to import/export packages and service to/from the parent framework into the composite bundle. The lifecycle of the constituent bundles are managed by the lifecycle of the composite bundle in the parent framework.

4.1.1 Simple composite description

A composite bundle is declared using a set of manifest-like headers, which is familiar to bundle developers and fits well with the virtual bundle proposal, where virtual bundles are installed with a given set of headers. Many existing The following headers are reused to declare for declaring a composite bundle, but not all are applicable (e.g., Bundle-ClassPath, Bundle-Activator, Bundle-NativeCode, Bundle-ActivationPolicy). Other than explicitly disallowed headers, all other headers maintain their normal meaning. For example, code dependencies are handled by:

• Import-Package - the packages imported by the composite bundle from the parent framework.
• Require-Bundle - the bundles required by the composite bundle from the parent framework.
• Export-Package - the packages exported by the composite bundle to the parent framework.

...

• Import-Service - the services imported by the composite bundle (exact syntax is yet to be defined, but a list of filters is a reasonable starting point).
• Export-Service - the services exported by the composite bundle (exact syntax is yet to be defined, but a list of filters is a reasonable starting point).

From the parent framework's perspective, the composite bundle is a normal bundle importing/exporting packages and services. Internally, the imported/exported packages and services are mapped onto and made available to the composite bundle's constituent bundles by the composite layer. A new header is introduced to declare the composite bundle's constituent bundles:

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

To simplify matching mapping a composite bundle's exported packages to its contained 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:

...

These declarative headers define the entire capabilities of a simple composite bundle. To summarize, these capabilities are: containing bundles, importing/exporting packages, requiring/providing bundles, and importing/exporting services.

NOTE 1: 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 derived from the actual injected wire. If the latter, then this relates to the rich wiring section in the open issues.

NOTE 2: Any "uses" constraints for the composite bundle's exported packages must be specified in the metadata, like normal. The parent framework will be able to ensure consistency like normal.

4.1.2

...

Simple composite lifecycle management

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.

...

4.2 Extended composite model

4.2.1 Extended

...

composite description

This proposal introduces one final header, which is:

...

The provided bundles will be manifested in the parent framework as virtual bundles themselves.

4.2.2 Extended composite lifecycle management

5. Open issues

5.1 Rich wiring information

...