Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
resolver-1.0.0
-
None
Description
We have been discussing two approaches to using the resolver
1) Big bang resolve. This is where the client wants to attempt to resolve all currently unresolved resources in one go. Here the ResolveContext could return all the unresolved resources as optional resources. This makes fragment resolution more simple because the resolver is supplied the complete set of unresolved resources from the start. But it still has a drawback of not allowing an already resolved fragment to be attached to another host since there is no mechanism to pull in the already resolved fragment when resolving another potential host.
2) Single root resolve. Here the client wants to attempt to resolve each "root" resource individually. As we are populating the "root" resource additional resources get pulled in as they supply candidates for the requirements that need to be resolved. This approach also suffers from a similar fragment issue since fragments will not get automatically pulled into a resolve operation unless they are either the root resource or they provide a candidate capability needed to resolve some other requirement.
It would be useful if the ResolveContext could provide additional "on demand" resources that get pulled in as other resources are getting automatically pulled into the populate candidate phase.
I suggest we add a felix specific ResolveContext interface that can be optionally implemented in order to provide a method getOndemandResources(Resource host). This method would get called by the resolver as it pulls in resources during the populate candidates phase.