[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Getting the solution of a P2 resolve operation including missing requirements
|
Christoph,
Certainly quite a number of things things in Oomph could be generally
contributed to p2...
The problem is that this is also not without yet more additional effort
and I am only one person who "must" keep 4 project afloat and on the
train...
Also, if such additions are then generally used, they must be supported
as API, which makes it less easy to change for my own purposes, e.g.,
when I recently added support for ignoring negative requirements. No
doubt you've noticed that you cannot do so much interesting and useful
stuff with p2 without "internal" "APIs", so everyone doing interesting
p2 things ends up using various internal things...
Also, if Oomph relies on some feature being in a new/recent version of
p2 then those things cannot work with older versions of p2 where this
addition isn't present.
Regards,
Ed
On 02.01.2022 08:26, Christoph Läubrich wrote:
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
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev