Hi Richard,
I've given this issue some more thought and I realized that my
starting point stands (a copy of the original mail is at the end of
this one).
If I try to execute these steps:
g! deploy -s DA
g! deploy -s A@1.0.0.1
g! refresh
g! deploy -s DexA
The deployment of DexA fails. If I understood correctly our discussion
about bundle's location string (first mail quote after this one)and
OBR , it shouldn't fail since OBR should try to deploy A@1.0.0.2 as an
update of A@1.0.0.1 (or, at least, to install it using a different
location string).
The execution of the presented test case throws the following
exception (note I changed the output's bundle names and versions to
accommodate to the examples ones):
////////////////////////////////////////////////////////////////////
Target resource(s):
-------------------
DexA (1.0.0)
Deploying...
ERROR: Resolver: Start error - DexA
org.osgi.framework.BundleException: Unresolved constraint in bundle
DexA [413]: Unable to resolve 413.0: missing requirement [413.0]
osgi.wiring.bundle;
(&(osgi.wiring.bundle=A)(bundle-version>=1.0.0.2)(bundle-version<=1.0.0.2))
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at org.apache.felix.gogo.command.OBR.deploy(OBR.java:387)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.gogo.shell.Console.run(Console.java:62)
at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
at java.lang.Thread.run(Thread.java:636)
done.
////////////////////////////////////////////////////////////////////
After which bundle DexA is left installed (not resolved nor active) in
the framework:
g! lb
[... framework's bundles..]
411|Active | 1|DA (1.0.0)
412|Active | 1|A (1.0.0.1)
413|Installed | 1|DexA (1.0.0)
Am I missing something? Do you prefer I create a JIRA issue with the
bundles attached so you can do furtheranalysis?
Kind regards and thank you!
On 02/04/12 19:25, Richard S. Hall wrote:
Yes, you are using the same path when you try to install the first
bundle the second time and this will not work since that path is used
as a unique key, which is why it returns the same bundle id as
printed in your session since it did not install anything the second
time.
As I suggest you need to have two different paths.
However, this isn't an issue for OBR since it uses an arbitrary
location string, so it is always unique when it does an install,
which you can't easily do from the shell, like I said before.
Matias SM<matias...@yahoo.com.ar> wrote:
[....deleted some mails for ease of reading ...]
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 -sA@1.0.0.1
==> this __updates__ the previously deployed A (version 1.0.0.2)
First "issue", if I run:
g!deploy -sA@1.0.0.2
==> then OBR executes successfully butA@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
==> soA@1.0.0.2 is completely uninstalled from the framework
And then:
g!deploy -s DexA
==> this deployment __fails__ becauseA@1.0.0.2 can't be
reinstalled in the framework!!
Not sure why that would be. Are you seeing some sort of error?
---------------------------------------
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.
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.
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.
