felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matias SM <matias...@yahoo.com.ar>
Subject Re: OBR and automatic bundle update
Date Mon, 02 Apr 2012 19:42:28 GMT
Thank you for your answer Richard, please see my comments inline:

On 02/04/12 14:40, Richard S. Hall wrote:
> On 4/1/12 12:32, Matias SM wrote:
>> Hi everybody,
>> I'm using OBR to help me resolve bundle deployment. Everything works 
>> great and as expected but I'm facing a situation I don't know how to 
>> solve.
>> ---------------------------------------
>> Here is my test scenario:
>> I have the following bundles in an OBR repository:
>> * SymbolicName: A | Bundle-Version: | exports: (package: 
>> "p.a" version: 1)
>> * SymbolicName: A | Bundle-Version:| exports: (package: "p.a" 
>> version: 1)
>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a" 
>> version: [1 , 2) )
>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a" 
>> version: [1 , 2) ) and (bundle: "A" version: [,] )
>> Then my test runs as follows:
>> g! deploy -s DA
>>     ==> this also deploys A version (I guess because it is 
>> the "newer" bundle that exports "pa" version 1)
>> g! deploy -s A@
>>     ==> this __updates__ the previously deployed A (version
>> First "issue", if I run:
>> g!deploy -s A@
>>     ==> then OBR executes successfully but A@ is not installed 
>> (since there is an "updated" version of it already resolved). I know 
>> this is the expected behavior, but I would like to be able to deploy 
>> A@
> It seems like OBR should probably be performing a refresh after it 
> does an update, so there isn't an older version hanging around.
>> Second (and worse) issue, if I now run:
>> g!refresh
>>     ==> so A@ is completely uninstalled from the framework
>> And then:
>> g!deploy -s DexA
>>     ==> this deployment __fails__ because A@ can't be 
>> reinstalled in the framework!!
> Not sure why that would be. Are you seeing some sort of error?

I think that the "problem" here is that to be able to update the 
dependency again to A@, OBR should withhold A@ (that was 
deployed in step 2). I don't think this should be a valid thing to do.

>> ---------------------------------------
>> In the OBR project web page [1] can be read:
>> "OBR's deployment algorithm appears simple at first glance, but it is 
>> actually somewhat complex due to the nature of deploying 
>> independently developed bundles. For example, in an ideal world, if 
>> an update for a bundle is made available, then updates for all of the 
>> bundles satisfying its dependencies are also made available. 
>> Unfortunately, this may not be the case, thus the deployment 
>> algorithm might have to install new bundles during an update to 
>> satisfy either new dependencies or updated dependencies that can no 
>> longer be satisfied by existing local bundles. In response to this 
>> type of scenario, ___the OBR deployment algorithm tries to favor 
>> updating existing bundles, if possible, as opposed to installing new 
>> bundles to satisfy dependencies.____"
>> I don't fully understand this explanation but I get that the 
>> described behavior is as intended.
> Not sure which part you don't understand.

What I don't understand is how the need to favor updating existing 
bundles is concluded from the problem stated in the previous sentences. 
It is not clear to me the relation between the need to "install new 
bundles during an update" and the algorithm that "tries to favor 
updating existing bundles instead of installing new ones".

>> My questions are:
>> 1- Is there a way to force the installation of different bundle 
>> versions (instead of the update of "older" ones) when deploying 
>> through OBR?
> No, I don't think so.
>> 2- What kind of issues may this behavior (installation of different 
>> versions) rise? (this is not considering the "problem" of having a 
>> lot of bundles installed)
> Lots of providers is generally a bad thing since it creates many 
> partitions in the overall class spaces of the bundles, meaning that 
> collaboration among them becomes limited to little islands of bundles 
> that happen to be using the same same providers.
I understand. But updating the bundles may lead to the problem I 
presented, where a bundle can't be resolved despite all necessary 
resources are available.

I know that this behavior is not defined by OBR but OSGi in general. But 
I don't understand why once a bundle is updated, an older version of it 
can't be re-installed so a bundle depending on it can be successfully 
resolved. I think that allowing this may help to avoid problems like the 
one presented (note that I have almost no experience with OSGi so maybe 
I'm talking nonsenses). Do you know the reason to "forbid" the 
installation of an old version of an updated bundle?

>> Note that while I'm using the shell to run my tests, my intention is 
>> to use the OBR API in my code. So the "solution" may be available 
>> only in the API.
>> Sorry the mail got so long but I wanted to state my problem as clear 
>> as possible.
>> Thank you for taking the time to read and to answer!
> Still not clear to me what the actual issue is or the solution, but at 
> a minimum OBR should probably refresh after update.

The issue is that the DexA bundle can't be resolved despite A@ is 
available in the repositories. I don't get how refreshing would solve 
the problem since A@ can't be installed because A@ is 
recognized as an update of it.

Thank you again for taking the time to respond to me!

> -> richard
>> Kind regards
>> [1] 
>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message