Re: [platform-dev] Getting the solution of a P2 resolve operation includ

[Christoph Läubrich <laeubi@xxxxxxxxxxxxxx>]

Thanks Ed,

thanks for sharing this, looking at the effort taken into this Util 
methods I wonder if it would make sense to contribute those to P2 so 
they are generally available?

With some testing I have now chosen an incremental approach instead that 
generates some intermediate IUs that are later removed from the set of 
resolved units by extracting the missing requirements from the 
explanation [1].

That has the advantage for my use case that I don't need to modify the 
IUs back as they are used later on to resolve other stuff as well.
Now I get a all resolvable items and a list of unresolved requirements 
as well.

[1] https://github.com/eclipse/tycho/pull/468

Am 31.12.21 um 10:26 schrieb Ed Merks:
> Christoph,
>
> The approach that we took with using p2 to implement Targlet support is 
> to transform all the metadata such that resolution meets our needs:
>
> https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.p2.core/src/org/eclipse/oomph/p2/core/P2Util.java#n223 
>
>
> For the specific case you describe, making all the requirements optional 
> and greedy ensures that all requirements that can be resolved are 
> resolved but failures to resolve a requirement do not fail the overall 
> resolution.
>
> This does not get you two sets of things though.  You'd still need to 
> check afterwards if any non-optional requirement is unsatisfied to get 
> your second list.   But that's iterating over all the resolved IU's 
> requirements and querying each against the other resolved IUs to collect 
> that list of unresolved requirements...
>
> Regards,
> Ed
>
>
> On 30.12.2021 20:09, Christoph Läubrich wrote:
> > I'm currently investigate if it is already possible to get a result 
> > from the Projector.invokeSolver call even if the result is not 
> > resolvable.
> >
> > What I want to archive is to resolve a state as if all missing 
> > requirements are there (and just reported as such).
> >
> > For example I have a bundle that is missing an import package, then I 
> > get the error:
> >
> > Software being installed: tycho.bundle 1.0.0.qualifier
> >  Missing requirement: tycho.bundle 1.0.0.qualifier requires 
> > 'java.package; my.missing.package 0.0.0' but it could not be found
> >
> > I now wanted to get two "sets":
> >
> > 1) all resolved items as if the package was not missing
> > 2) all missing requirements (in this case the missing package)
> >
> > What I could think of is to do this in an incremental way, eg. first 
> > try to resolve, then get the missing items and create a new resolver 
> > run with a dummy unit providing the missing item and thus keep track 
> > of all these dummy items in a list.
> >
> > I just wanted to make sure that I'm not missing an existing function 
> > that already do this.
> > _______________________________________________
> > platform-dev mailing list
> > platform-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit 
> > https://www.eclipse.org/mailman/listinfo/platform-dev
> _______________________________________________
> platform-dev mailing list
> platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev