One clarification on import/export. If your bundle X is a "container" bundle as BJ describes and it imports/exports the packages AND its imports resolve to another bundle then the bundle is effectively "empty" as BJ describes. But there is one important thing to note about such an empty bundle: Other bundles that happen to require bundle X will now "wire" to the substituted packages that bundle X wires to which replaced/substituted the packages declared to be exported by bundle X.
The other thing to note about this scenario that involves system packages. The framework *still* does not know what version to export the packages included in the VM. For example, the javax.annotation packages below. I imagine (but don't know for certain) that the javax.annotation packages include in java 8 would be at version 1.2 or higher, but the framework does not know that so it just exports them at version 0.0.0. So even though you import/export at version 1.2.0 the package still will not be substituted with the VM package on Java 8. So we will end up with two exporters of the annotations package. Tom From: BJ Hargrave/Austin/IBM@IBMUS To: Equinox development mailing list <[email protected]> Date: 07/11/2014 09:28 AM Subject: Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by: [email protected] Importing what you export is only useful when the bundle contains other packages which actually use the exported package. For example, a bundle implements the OSGi Event Admin service. That bundle can export the org.osgi.service.event package and also import it. The bundle is happy to use any (version matching) org.osgi.service.event package. But if the bundle is just a "container" of packages which it exports for other and does not itself use the packages in anyway, then there is less value in also importing the packages. Say a bundle just contains the org.osgi.service.event package and exports it as well as imports it. If this bundle is resolved to import the package, the bundle is essentially empty. It is not exporting the package and has no other packages. I don't know the make up of the bundles in question here. But is may or may not make sense to import the packages being exported. What the bundle contains will influence the choice. That being said, there is little harm in also importing the packages, so it is a safe (but perhaps of little value) choice. -- BJ Hargrave Senior Technical Staff Member, IBM office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788 [email protected] From: Andreas Sewe <[email protected]> To: [email protected], [email protected] Date: 2014/07/11 04:38 Subject: Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by: [email protected] David M Williams wrote: > I notice in Orbit, all our "javax.annotation" bundles follow the import > what you export pattern .... that's good, such as > > *Export-Package*: javax.annotation;/version/="1.2.0", > javax.annotation.security;/version/="1.2.0", > javax.annotation.sql;/version/="1.2.0" > *Import-Package*: javax.annotation;/version/="1.2.0", > javax.annotation.security;/version/="1.2.0", > javax.annotation.sql;/version/="1.2.0" Is this "import what you export" best practice for *all* javax.* bundles in Orbit? As far as I can see, some of them don't follow this policy (javax.xml.bind, for example, whose packages are also provided by the system bundle provides at least from Java 7 onwards) and I am wondering whether it's worth opening bugs for this. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 _______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
