Provisioning and resolution - Enterprise OSGi in Action - page 169

THE RESOLUTION DIRECTIVE
The resolution directive serves a fairly simple purpose; it determines whether a
requirement is optional or not. The resolution directive has two allowed values,
optional and mandatory . The default value of this directive is mandatory.
The resolution directive can be applied to any requirement, and it's also possible
to specify it on requirement-like manifest headers:

Import-Package: fancyfoods.optional; resolution:=optional
Require-Bundle: fancyfoods.needed.bundle; resolution:=mandatory

WARNING: DIRECTIVES IN THE BUNDLE MANIFEST At first glance, there doesn't
seem to be any difference between the resolution directive and any other
attribute on an Import-Package ; however, if you look closely you'll see that
it's specified using := , not = . This is the key difference in syntax between an
attribute and a directive. If you were to write resolution=optional , then
your package import would still be mandatory and the resolver would try to
find an exported package that defined an attribute called resolution with a
value of optional .

THE MANDATORY DIRECTIVE
The mandatory directive is somewhat more complicated than the other directives, pri-
marily because it doesn't apply to a requirement, but instead to a capability. Many peo-
ple get confused by what the mandatory directive does, but there's a reasonably simple
way to think about it. When you specify attributes on a requirement, it means that the
requirement can only be satisfied by a capability that provides all of those attributes;
however, any capability that provides those attributes will do, even if it specifies a hun-
dred extra attributes. The mandatory directive effectively provides the reverse map-
ping of this behavior. By using the mandatory directive, a capability can specify a set of
attributes that a requirement must specify to be matched. Even if the capability sup-
plies all of the attributes needed by the requirement, it won't match unless the
requirement supplies all of the mandatory attributes:

Importing
bundle manifest

Bundle-SymbolicName: A
Import-Package: fancyfoods.mandatory; chocolate=nice

Bundle-SymbolicName: B
Export-Package: fancyfoods.mandatory; chocolate=nice;
cheese=yummy; mandatory:="chocolate,cheese"
In this code snippet, you can see that the package import from bundle A looks as
though it should match the export from bundle B. Bundle B, however, only allows
importers that specify both that chocolate is nice and that cheese is yummy. As a
result, poor bundle A must look elsewhere for its package (see figure 7.4).
The mandatory directive is a specialized tool, and we recommend avoiding it
unless you really need it. One example of why you might want to use the mandatory
directive is if you have a private SPI package that needs to be shared between two bun-
dles (yuck!). In this case, you can add a mandatory attribute to the exported package
so that you can't wire to it accidentally, only if you supply the necessary attribute. Even

Exporting bundle
manifest