Is runtime dependency resolution supported in OBR?

[Krishanu <co...@gmail.com>]

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.

-- 
View this message in context: http://www.nabble.com/Is-runtime-dependency-resolution-supported-in-OBR--tp21291746p21291746.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Is runtime dependency resolution supported in OBR?

["Richard S. Hall" <he...@ungoverned.org>]

Richard S. Hall wrote:
> 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.

Should say, "It would be fairly easy..."

>
> 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?).

Should say, "(e.g., should it get all available...)"

Tired, I guess.

-> richard

>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Is runtime dependency resolution supported in OBR?

["Richard S. Hall" <he...@ungoverned.org>]

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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org