- 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. 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. On Wed, Nov 16, 2016 at 4:44 AM, Pascal Rapicault <pas...@rapicault.net> 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 listequinox-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev >
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
