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@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Reply via email to