On 11/30/09 17:03, martin liste larsson wrote:
Thanks for the input. I think maybe the bnd-tool is adding that broad import.
Maybe I shouldn't use bnd after all, or at least learn it before I use it... :*)
Yes, BND by default generates imports for exports, but you can easily
tell it not to...check the docs.
-> richard
As I said earlier, neither of these are OSGi-bundles, just plain
jar-files without sources.
So I can pretty much define the versions and exports and imports
myself. I'll have to
decide what's logical for this case.
M.
On Mon, Nov 30, 2009 at 4:36 PM, Richard S. Hall<he...@ungoverned.org> wrote:
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: 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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
