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... :*)
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 <[email protected]> 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: [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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
