On 11/30/09 10:20, martin liste larsson wrote:
I have a situation where bundle A and B both depends on C, but on
different versions
(A on C version 1, B on C version 2). In the actual situation, none of
these are actual
bundles, but rather plain JAR-files. They will be supplied by a third
party, so I won't be
able to recompile A to upgrade to version 2 of C (it might not even be
possible).
After a lot of wasted time, I made it work by making both versions of
C explicitly
importing it's own version. IOW:
Export-Package: com.package.some;version="1.0.0"
Import-Package: com.package.some;version="[1.0.0,1.0.0]"
(and likewise for version 2.0.0:
Export-Package: com.package.some;version="2.0.0"
Import-Package: com.package.some;version="[2.0.0,2.0.0]"
).
Is this really necessary? Why won't A and B connect to the correct
C-version with
Import-Package: com.package.some;version="[1.0.0,2.0)"
for A, and
Import-Package: com.package.some;version="2.0.0"
for B?
The error I got was:
org.osgi.framework.BundleException: Unresolved constraint in bundle A
[35]: package; (&(package=com.package.some)(version>=1.0.0)(!(version>=2.0.0)))
when both versions of C was in the 'Active' state.
If anyone has any comments, I'd be grateful.
I'd assume that your old version of C is importing its own package with
too broad of a version range, which causes it to get wired to the new
version instead of itself. If C is just a library bundle providing some
packages at a specific version, then don't have it import its own
packages, just have it export only then you should be fine.
-> richard
Thanks,
M.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
