Resolver, requirements, capabilities, and start levels

The resolver turns declarative requirements into a consistent wiring graph.

Generic model

A resource provides capabilities and declares requirements in named namespaces. Package imports/exports are one namespace. Others describe bundle identity, execution environment, services, native code, or custom features.

Provide-Capability: com.acme.device;
  device.type=charger;
  version:Version=2.0
Require-Capability: com.acme.device;
  filter:="(&(device.type=charger)(version>=2.0))"

The resolver recursively finds resources whose capabilities satisfy mandatory requirements. A successful resolution is a graph, not just a list of JARs.

Effective directives

Some requirements matter at resolve time; others, commonly service requirements, are effective:=active. Build tools can use active requirements to assemble a complete application even when the framework does not wire them as package dependencies.

Optional requirements

Optional means resolution can succeed without the capability. Application behavior must still be correct without it. Do not use optional as a way to hide an unknown dependency.

Start levels

Framework and bundle start levels stage activation. They are an operational ordering tool, not a dependency mechanism. A component should express required services; it should not assume another bundle is ready because its numeric start level is lower.

bndrun

A .bndrun file declares the framework, execution environment, repositories, and initial requirements. bnd resolves these into -runbundles, producing a repeatable closure and reasons for every selected resource.

Feynman check

A resolver proves that declared needs can be supplied. It does not prove a database is reachable or a business rule is correct. Name the evidence needed for those separate claims.