On Mon, Aug 8, 2016 at 4:37 PM, Thomas Watson <[email protected]> wrote:
> 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. > Ok, with further digging I finally managed to find the fragment that hosted the capability in the wiring result of the resolver. Thanks for sounding off on this. - Ray > > 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 > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
