Never use reexport on require-bundle. It makes require bundle even more evil (if that is possible!).
I recommend augmenting your pattern below with an Export-Package from bundle A: Bundle-SymbolicName: a; Require-Bundle: b, c Export-Package: com.company.util Bundle-SymbolicName: b Export-Package: com.company.util;b=split;mandatory:=b Bundle-SymbolicName: c Export-Package: com.company.util;c=split;mandatory:=c This at least will control the API footprint of Bundle A to be the complete split package com.company.util instead of pulling in ALL packages exported from the required bundles B and C. This will also allow normal importers to actually get wired to the correct "full" package com.company.util exported by bundle A since bundle A will export the aggregate package with no mandatory directives. Tom From: David Bosschaert <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 01/22/2013 04:55 AM Subject: [osgi-dev] What's the best way to deal with split packages? Sent by: [email protected] Hi all, I'm trying to understand what the best way is to deal with split packages in an OSGi environment, assuming that it's not an option to bluntly rename those packages. I found this fairly old post from Chris A. that seems to give a possible way of working with these: http://eclipsesource.com/blogs/2008/08/22/tip-split-packages-and-visibility/ Effectively the post boils down to merging the split packages of bundles b and c into bundle a: Bundle-SymbolicName: a; Require-Bundle: b;visibility:=reexport, c;visibility:=reexport Bundle-SymbolicName: b Export-Package: com.company.util;b=split;mandatory:=b Bundle-SymbolicName: c Export-Package: com.company.util;c=split;mandatory:=c And I guess when you import com.company.util the resolver does not bind you directly to b or c because of the b=split;mandatory:=b Am I correct that this is ordinary use of OSGi package attributes combined with the mandatory directive that should work in any framework? Or is there something equinox specific in there? Or... does anyone have a better alternative? Many thanks, David_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<inline: graycol.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
