From my point of view it should be ReqA, because there are no
candidates available (that can be resolved) to satisfy this constraint.
I understand why you think it is misleading, but in reality it would be
misleading to report ReqFOO too, since the installer of ResourceA may
know about ReqA, but it will not necessarily know about ReqFOO from some
transitive dependency. So the installer might be wondering why that is
getting installed when he doesn't even want that artifact...in my view,
that would be more confusing.
This situation gets worse when "uses" constraints are involved, which is
something that OBR still needs to address.
-> richard
David Albert wrote:
Hello,
I've been doing some work implementing OBR for Concierge, and I'm
running into some trouble with multiple levels of dependencies.
Consider the following situation: I want to install ResourceA which
has one requirement, ReqA. ReqA can be satisfied by capabilities in
either ResourceB or ResourceC, both of which are in our repository.
ResourceB and ResourceC both have requirements that we are unable to
resolve, thus we cannot install them. Which requirements should be
returned by getUnsatisfiedRequirements()? My best guess would be
ReqA, but this seems a bit misleading because we have both ResourceB
and ResourceC in our repository. Thoughts?
Best,
-David
--
David Albert
Bug Labs
------------------------------------------------------------------------
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
