OBR does not really support run-time dependency resolution. I would be
fairly easy to create resources at run time that you could ask OBR to
resolve, but that is not really the hard part.
OBR is not really geared toward run-time service dependency resolution,
since it is hard to know which to choose. Typically you'd want to make a
selection based on some non-functional characteristics. But even if you
just want it based on service interface type, OBR doesn't really have a
way to know how it should treat optional service dependencies (e.g.,
should they always be resolved if possible?) or aggregate service
dependencies (e.g., should it all available or some subset?).
Only simple policies are possible in these cases. Coming up with a "best
fit" policy is difficult, unless we have some way of describing what a
"best fit" is.
I think this is an interesting area, but it needs more exploration.
-> richard
Krishanu wrote:
I have 4 bundles. B2 has interface I1. B3 and B4 provide different
implementations of I1. So both B3 and B4 depends on B2. B1 uses I1 interface
and hence also depends on B2.
So for B1 to work properly; B1, B2 and either or both of B3 and B4 needs to
be in OSGi runtime. When we use OBR service and deploy B1, its compile time
dependency: B2 gets installed in runtime, automatically. This is because
these dependencies are represented in the repository.xml file. However, what
about the runtime dependencies of B1?
Is there a way to depoly B1 so that the best fit among B3 and B4 will
automatically get installed in runtime. Or do the developer has to
independently deploy either B3 or B4 or both along with B1. What is the best
practice?
Note: I understand that if both B1 and B2 are in runtime, OSGi knows how to
choose the proper one using constraints(if at all required). I also
understand, that if B1 has B3 or B4 as its required bundle, it will resolve
the dependency, but then the whole purpose of making the impl dynamically
available is lost.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
