The difference between what BND is doing and what I understand you are trying to do is that BND always starts with a fresh slate and does a full resolve to pull in the required resources to run. But you want to start from a persistent state which is the set of things already provisioned to a framework and possibly resolved.
The key concept to understand is that the Resolver service is stateless. All state must be kept by the implementation of the ResolveContext used to do the resolve operation. The Resolver gets the current state by calling org.osgi.service.resolver.ResolveContext.getWirings(). This is the starting "context" the resolver must apply new resolution wires to. If you have a running framework then you can gather all the Wiring objects for each bundle revision (BundleRevision implements Resource) by calling org.osgi.framework.wiring.BundleRevision.getWiring().
With that you can produce the Map<Resource, Wiring> wirings to hand the Resolver. What I recommend is that you back your ResolveContext with at least two Respository implementations (or concepts).
1) to represent the resource/capabilities installed in the framework. This can trivially be implemented by using the method org.osgi.framework.wiring.FrameworkWiring.findProviders(Requirement)
2) to represent one or more repositories you want to use to install more resources to the framework in order to satisfy additional requirements.
Then in org.osgi.service.resolver.ResolveContext.findProviders(Requirement) you can implement a policy where you can prefer capabilities from resources already installed over ones available from repository #2.
When the Resolver.resolve method hands back a Map<Resource, List<Wire>> it has not actually been applied to the state maintained by the ResolveContext. That is something that still needs to be applied by the code calling the Resolver.resolve method. For you that may simply mean installing each Resource key in the map as a bundle. Then you should likely do a framework resolution operation to ensure what you provisioned does really resolve at runtime. Then next provisioning operation you will start over with a wiring state that includes again all the current BundleWiring objects.
HTH
Tom
----- Original message -----
From: Cristiano via osgi-dev <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: Raymond Auge <raymond.a...@liferay.com>, OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: Re: [osgi-dev] what is way to use a Resolver and Repository together ?
Date: Mon, Dec 3, 2018 1:26 PM
On 01/12/2018 19:32, Raymond Auge wrote:
> The basic idea is that you want to represent the capabilities of the
> existing system as already being provided, used to support the
> requirements you're searching for, but ultimately excluded from the
> result, such that only missing capabilities are included in the result.
>
> You might want to look at
> https://github.com/bndtools/bnd/blob/master/biz.aQute.resolve/src/biz/aQute/resolve/BndrunResolveContext.java
> and note how when using a "distro" (a predefined set of provided
> capabilities) it performs exactly this logic.
>
> Hth,
> - Ray
Hi Raymond,
Thanks again for your support. ;)
I was thinking that I had understood the concept you exposed, but
looking at the example.... wow, it is more complex than I was expecting.
My understanding until now was that I would somehow mount a "snapshot"
of the node using a ResolveContext object and then call the
Resolver.resolve(). After that, to call the repository's findProvider()
using somehow the built snapshot...
but BndrunResolveContext receives a Repository instance on it
constructor. Why would I need a repository inside the context?
best regards,
Cristiano
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
