Best regards
On Thu, Nov 17, 2016 at 6:20 AM, Pascal Rapicault
<[email protected] <mailto:[email protected]>> wrote:
On 11/16/2016 10:49 AM, Todor Boev wrote:
- Regarding resolver behavior:
The goal is actually to replace the behavior of the objective
function with the behavior of the resolver. This is the best way
to guarantee that both p2 and the OSGi runtime agree on what is a
consistent set of bundles. For example p2 does not take into
account package uses constraints which leads to p2 selecting
bundles that later fail to resolve at runtime. It does not matter
which way to resolve is better, so long as they agree. Since the
OSGi resolver is very unlikely to change it falls on p2 to match
it's behavior. My current company (software ag) has had quite a
number of issues where essentially p2 sets up the resolver to fail.
- Regarding resolver scalability:
The resolution is split between the resolver which processes
the current set of resources and the resolver context which
selects candidates when asked. If the goal is to support a very
high number of candidates - a resolver context impl optimized for
searches in a large candidate space can be provided. If the goal
is to produce a solution that includes a very high number of
resources - more research is required. Even if the initial set is
10,000 the resolver can be asked to process them not all at once,
but incrementally in batches or even one by one. Which is in fact
what equinox does today.
The thing is that if you look at a subset of the available
bundles, you may find a solution that is not the optimal one. p2
will consider all the possible candidates in one resolution
invocation.
I am trying to determine if it makes sense to invest effort in
prototyping this given that subtle changes in behavior are in
fact a goal, rather than an issue.
Even though on the surface p2 resolver looks similar to what
the OSGi resolver does, p2 has at least 2 additional concepts:
1) the expression of strict negation
2) the concept of patch
I'm tempted to think that it is probably simpler to add support
for the uses-clause in p2 (this has been a known issue for years,
but I can't seem to find the bug tonight) than it is to replace
the resolver completely and get all the tests to pass. The
encoding of dependencies to a SAT formula is well documented and
so are the optimization functions.
On Wed, Nov 16, 2016 at 4:44 AM, Pascal Rapicault
<[email protected] <mailto:[email protected]>> wrote:
On 11/15/2016 12:52 PM, Todor Boev wrote:
Hello,
Are there any plans to bring together p2 and OSGi
resolver+repository standards?
There is no immediate plan for this.
It should be beneficial to have similar (maybe identical?)
dependency resolution at provisioning time and later at runtime.
The install time and runtime resolvers resolve a slightly
different problem because the install time resolver has to
look for candidates in a large space, whereas the runtime one
has to connect as many components together.
I have not tried replacing the p2 resolver with the new
OSGi resolver so I can't tell how it would perform.
Specifically:
- Is it possible to publish the bundle generic
capabilities/requirements to the p2 repository?
Yes this should be possible. The underlying p2 capability
/ requirement model is really extensible and the current
limitation is only the serialized format.
- Is it possible to use the equinox Resolver inside the p2
Planner?
It is possible to get something going but I'm not sure if
this will scale (p2 resolver is able to perform seamlessly on
10's of thousands of IUs), nor if you will be able to
replicate the subtleties that result from having an objective
function.
- Even if the equinox Resolver can not be used is it
possible for p2 to handle generic requirements/capabilities?
Yes. This should not be too much work.
Regards,
Todor Boev
_______________________________________________
equinox-dev mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
_______________________________________________ equinox-dev
mailing list [email protected]
<mailto:[email protected]> To change your delivery
options, retrieve your password, or unsubscribe from this
list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
_______________________________________________
equinox-dev mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
_______________________________________________ equinox-dev
mailing list [email protected]
<mailto:[email protected]> To change your delivery options,
retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
_______________________________________________
equinox-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
