On 11/30/09 10:34, Richard S. Hall wrote:
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.
p.s. If C does have service interfaces or something that you want to be
substitutable, then make sure you limit its import range to be [1.0.0,
2.0.0)...there is little point in making it [1.0.0, 1.0.0] since this is
nearly the same as not importing at all, so you might as well do that if
you don't want substitutability.
-> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
