On 11/24/12 17:56, Gareth Collins wrote:
Hello Richard,
Thanks very much for the quick response!
SCENARIO 6
RESULT {osgi.identity; A=[]}
SCENARIO 7
RESULT {osgi.identity; A=[osgi.wiring.package; (osgi.wiring.package=A)
-> [osgi.identity; B]], osgi.identity; B=[]}
This is not correct behaviour, is it?
Why would it not be correct? It is a valid resolution, isn't it? The
resolver is only required to give a valid resolution or fail.
It is a valid resolution, but it is not an optimal resolution
There is no way the resolver could ever attempt to find an optimal
resolution, that would be too costly. It only attempts to find a valid
resolution.
and
leads to problems resolving with real R5 repositories.
For example, if I have an R5 repository (for example from
bnd/bndtools) with the following three bundles:
osgi.cmpn 4.2
Felix Config Admin 1.2.8
Felix Config Admin 1.4.
and I try to resolve Felix Config Admin 1.4 with the following package
imports:
org.apache.felix.cm {version=[1.0,1.1)}
org.apache.felix.cm.file {version=[1.0,1.1)}
org.osgi.framework {version=[1.4,2)}
org.osgi.service.cm {version=[1.4,1.5)}
Given the current logic org.osgi.service.cm will resolve against
osgi.cmpn as it is first. org.apache.felix.cm and
org.apache.felix.cm.file will resolve against Felix Config Admin 1.2.8
as it appears before 1.4.0 in
the capability list. I don't think this is a valid bundle install list.
The resolver looks at things as packages and all things being equal it is
free to choose whichever provider it wants based on a set of priority rules.
No matter which rules you choose, there are always going to be cases that
aren't optimal.
The question is, is the result valid or not? If it is valid, then it is
fine. If it isn't valid, then there is either a bug in the resolver or the
bundle metadata.
If Config Admin 1.4 shouldn't be able to get packages from Config Admin
1.2.8, then the metadata associated with the associated
capabilities/requirements should make that impossible. You cannot expect the
resolver to know that you prefer that to not happen when you give it
metadata saying it is ok if it happens.
Or are you saying that something outside of the resolver (i.e.
bnd/bndtools) should fix this sort of problem? Or should a valid R5
repository perhaps not contain both a felix config admin 1.2.8 and
felix config admin 1.4.0?
No. I'm saying you shouldn't expect an optimal solution, you should just
expect a valid solution. I have yet to see an issue here as long as the
resolutions are valid.
Let me know if I am missing
something obvious here.
I'm not exactly sure what is going on here, but for bundles I'd expect
you'd
see something similar in the framework, since packages from bundles
installed earlier are given preferences over bundles installed later.
Ordering has always been important in the framework, if I recall
correctly,
since bundle ID was used as a tie breaker if all else was equal.
-> richard
I agree. Already installed bundles should have priority. But shouldn't
the current
resource list in the resolve result have priority over other potential
bundles to install?
Or is this something that should be dealt with outside the resolver?
It could be, but it is just another heuristic that may not always be right
and one that is not mentioned in the spec.
And technically, the way that the R5 resolver is implemented, the actual
resolver really plays no role in determining the priority of candidates. It
is actually the ResolveContext implementation that determines that.
But it would be possible for a ResolveContext implementation to prioritize
resolving bundles higher than non-resolving ones, but this would be
implementation specific.
-> richard
thanks in advance,
Gareth
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
