The capabilities returned by ResolveContext#findProviders must return the real capabilities that come from the resource itself. This would be the fragment resource. The ResolveContext does not return "hosted" capabilities. The resolver then takes these capabilities and if they are from fragments it should figure out how to host them if the capability is considered a pay-load capability. This will ultimately pull in the fragment resource into the resolution which could also end up pulling in a host resource in order to resolve the fragment resource that provides the original capability.
I'm unsure I have answered your question. Mainly because I don't know what you meant by "How should I expect to discover the fragment that provided the capability when the returned candidates only contains the host bundle?" It sounds like you have a ResolveContext that is returning a 'hosted' capability instead of the real one that was actually provided by the fragment resource getCapabilities() method. Fragments are the worst and really complicate the resolver design and implementation. Tom. On Mon, Aug 8, 2016 at 1:44 PM, Raymond Auge <[email protected]> wrote: > Hello All, > > I'm stepping through the resolver (executed via bndtools). > > I'm having a little bit of a hard time understanding a few details: > > Given the following line: > > List<Capability> candidates = rc.findProviders(requirement); > > - where "rc" is a ResolveContext > - where "requirement" is a capability provided by a fragment > > How should I expect to discover the fragment that provided the capability > when the returned candidates only contains the host bundle? > > Should this have been persisted into the resolve context somehow? > > Sincerely, > - Ray >
