3.6.3 Optional Packages

[thomas.diesler]

3.6.3 Optional Packages

https://jira.jboss.org/jira/browse/JBOSGI-143

A bundle can indicate that it does not require a package to resolve correctly,
but it may use the package if it is available. For example, logging is important,
but the absence of a log service should not prevent a bundle from running.
Optional imports can be specified in the following ways:

Dynamic Imports: The DynamicImport-Package header is intended to
look for an exported package when that package is needed. The key use
case for dynamic import is the Class forName method when a bundle
does not know in advance the class name it may be requested to load.

Resolution Directive: The resolution directive on an import definition
specifying the value optional. A bundle may successfully resolve if a
suitable optional package is not present.

The key difference between these two mechanisms is when the wires are
made. An attempt is made to establish a wire for a dynamic import every
time there is an attempt to load a class in that package, whereas the wire for
a resolution optional package may only be established when the bundle is
resolved.

[thomas.diesler]

Ales sais,

Just found this in RequirementDependencyItem

 // Optional requirement
 if (requirement.isOptional() || requirement.isDynamic())
 setResolved(true);

[adrian.brock]

The issue here is that the dynamic import metadata isn't getting mapped to
a PackageRequirement at the moment (see OSGiBundleClassLoadingDeployer for the TODO).

The reason I haven't done it, is because the OSGi metadata lets you specify
the packages using wildcards, while the current jboss implementation
only lets you do explicit package names.

See
org.jboss.classloading.spi.dependency.policy.DynamicClassLoaderPolicyFactory
and related classes.

I could make your test work (since it doesn't use wildcards) but that wouldn't be the
full solution.

There's a similar issue for the "uses" constraint.