...

If a composite provides multiple bundles, then shared and potentially conflicting packages among the provided bundles would need to be correctly modeled. For each provided bundle, a package space would need to be calculated for any imported package participating in a uses constraint. Any common packages with the same provider among the provided bundles would need to be modeled on a common uses constraint bundle in the parent framework, where the same package coming from different providers would need to be modeled with a separate uses constraint bundles. Non-overlapping packages could be lumped into a single uses constraint bundle. This algorithm would be non-trivial, but since it is just walking existing wires, it should not suffer from similar performance issues like the resolver algorithm.

Discuss: 3) lifecycle ops on provided bundles

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

NOTE: This approach requires richer wiring information as discussed in the open issues.

4.2.2.3 Lifecycle of proxied bundles

As discussed, the support for providing bundles results in the composite manager installing proxy bundles for the provided bundle and its uses constraints in the parent framework in addition to the original composite bundle. This raises questions about the lifecycle of proxied bundles.

The lifetime of the proxied bundles is dependent on the resolved lifetime of the associated composite bundle. If the composite is refreshed, then the provided bundles should be uninstalled and refreshed. (Technically, it would be possible to simply refresh them and leave them unresolvable.)

Performing individual lifecycle operations on the proxied bundles should function like normal in the parent framework, but should have no impact on the internals constituent bundles of the composite. For example, you can start, stop, and even uninstall provided bundles, but this just impacts the state of the bundles in the parent framework, which may render them unresolvable.

5. Open issues

5.1 Rich wiring information

Currently, the wiring information provided by the virtual bundle proposal has been kept purposely simplistic. To fully implement aspects of composites, like requiring/providing bundles, it is necessary to get richer information from the wires, such as the type of capability. Further, the wiring information needs to be at the module-level (i.e., bundle revision level), not at the bundle level. The refactoring of the Package Admin API addresses some of these issues, but not all of them.

6. Considered alternatives

...