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: 1.0.0.1 | exports: (package: "p.a"
version: 1)
* SymbolicName: A | Bundle-Version: 1.0.0.2| 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: [1.0.0.2, 1.0.0.2] )
Then my test runs as follows:
g! deploy -s DA
==> this also deploys A version 1.0.0.2 (I guess because it is the
"newer" bundle that exports "pa" version 1)
g! deploy -s A@1.0.0.1
==> this __updates__ the previously deployed A (version 1.0.0.2)
First "issue", if I run:
g!deploy -s A@1.0.0.2
==> then OBR executes successfully but A@1.0.0.2 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@1.0.0.2
Second (and worse) issue, if I now run:
g!refresh
==> so A@1.0.0.2 is completely uninstalled from the framework
And then:
g!deploy -s DexA
==> this deployment __fails__ because A@1.0.0.2 can't be
reinstalled in the framework!!
---------------------------------------
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.
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?
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)
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!
Kind regards
[1]
http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
