On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
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: 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
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@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!!
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@1.0.0.2, OBR should withhold A@1.0.0.1 (that
was deployed in step 2). I don't think this should be a valid thing
to do.
Still seems like it should be possible for OBR to deploy DexA by
updating 1.0.0.1 to 1.0.0.2.
Wouldn't that break the request that bundle A@1.0.0.1 is deployed (step
2 in test)?
---------------------------------------
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".
Ok, I see your point now. No, the one doesn't necessarily follow the
other. The reason to favor updating existing bundles is the reason I
gave below.
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?
You can re-install older versions. OBR will *only* update an existing
bundle if it still satisfies all existing constraints. If not, then it
will install another version, which will then give you both versions
installed at the same time.
There is no rule forbidding the installation of an old version of an
updated bundle. More than likely, we just aren't speaking the same
language. Perhaps you can open a JIRA issue with a simple example
recreating the scenario where you cannot install an older version of
an updated bundle. If so, I'll take a look.
mmm... but I can't do that even directly from the felix shell (at least
in Felix bundle version 4.0.2).
I will create an issue as you recommend, but you can recreate the
scenario simply doing:
- Installing a bundle
- Update it with another bundle differing only in its Bundle-Version (I
tested with just a qualifier change)
- A try to install again the first bundle will return the original
bundle id (i.e. the updated bundle's id) and the updated version will
remain
I thought it was the intended behavior.
-> richard
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@1.0.0.2
is available in the repositories. I don't get how refreshing would
solve the problem since A@1.0.0.2 can't be installed because
A@1.0.0.1 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
