Before we start: The Resolver works with the Requirements and Capabilities of OSGi and I strongly suggest to have a look at them, if you work with the Resolver.
To give an Answer to the question above, we take the following example output:
Resolution failed. Capabilities satisfying the following requirements could not be found: [<<INITIAL>>] ⇒ osgi.identity: (osgi.identity=org.gecko.test.bundle.fragment) ⇒ [org.gecko.test.bundle.fragment version=1.0.0.SNAPSHOT] ⇒ osgi.wiring.host: (osgi.wiring.host=org.gecko.test.bundle.host) ⇒ [org.gecko.test.bundle.host version=1.0.0] ⇒ osgi.service: (objectClass=org.gecko.test.bundle.ApplicationConfiguration) [org.apache.aries.jpa.container version=2.7.0] ⇒ osgi.service: (objectClass=javax.persistence.spi.PersistenceProvider)
Lets take it apart and look what it is telling us:
Resolution failed. Capabilities satisfying the following requirements could not be found: [<<INITIAL>>]
Surprise! Something went wrong and the line after
[<<INITIAL>>] represents one requirement given in the -runrequires that is the root cause for the current issue.
⇒ osgi.identity: (osgi.identity=org.gecko.test.bundle.fragment)
Bundle added via drag and drop and sometimes their versions are translated in OSGi Requirement filters for the osgi.identity Namespace.
⇒ [org.gecko.test.bundle.fragment version=1.0.0.SNAPSHOT]
In between  it will state the Bundle and Version found, that provides the requested osgi.identity.
⇒ osgi.wiring.host: (osgi.wiring.host=org.gecko.test.bundle.host)
The Bundle found is a Fragment and the Resolver thus found a Requirement for a Host Bundle.
⇒ [org.gecko.test.bundle.host version=1.0.0]
It also found a Host Bundle.
[org.apache.aries.jpa.container version=2.7.0] ⇒ osgi.service: (objectClass=javax.persistence.spi.PersistenceProvider)
A part like this is often the confusing one. The indentation tells you, that it has nothing todo with the last requirement stated. This part can be longer and have multiple entries, but they can usually be ignored for the time being.
The Important part was the last stated
osgi.service Requirement. It tells us, that there is no bundle in your workspace or repositories, that states that it provides a service of the given type. This is the problem you need to work with and figure out why. The most common end in such a chain is osgi.identity if somebody uses Require-Bundle and the Bundle can't be found or osgi.wiring.package if no Bundle can be found providing such a package.
The most common cause for a missing service, is if you have a service referenced via DS or CDI, where BND automatically generates
osgi.service Requirements for you. If the Service is registered via bundleContext.registerservice(...). In this case bnd is not picking this up and nobody provides such a requirement.
To solve this you have two choices:
If the Bundle registering the service manually is your own, add the following Annotation to the registering class:
@Capability(namespace = "osgi.service", attribute = "objectClass=org.gecko.test.bundle.MyService")
This will add the necessary Capability for you.
If the service is registered by a third party Bundle, you can tell the resolver to ignore the
osgi.service requirements. Please note, that this can cause problems at runtime, because there might be services missing, that you depend on. To do this add the -resolve.effective: active;skip:="osgi.service" instruction to your bndrun. For more details look here.
Fixing issues the resolver has, is a step by step process. Thus, after one issue is taken care of, you need to resolve again and tackle one problem at a time.
by Ilenia Salvadori, Mark Hoffmann, Jürgen Albert