---
title: "Resolver, requirements, capabilities, and start levels"
chapter: "04"
---

# 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.

```text
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.