Yes, you are correct Neil. The other packages you get from the require-bundle may be inconsistent with the package you are wired to with import-package. Uses constraints are the tool to prevent such inconsistent wirings.
Tom From: Neil Bartlett <[email protected]> To: Equinox development mailing list <[email protected]> Date: 12/11/2014 09:08 AM Subject: Re: [equinox-dev] Exporting packages without a version Sent by: [email protected] Hi Tom, yes I’m aware of that, however if there are different sets of packages exported by the two versions then you may get visibility of some packages through Require-Bundle instead of Import-Package. Since I didn’t see any “uses” constraints on the exports, isn’t it possible that the imported packages would then have visibility of an incorrect set of dependent packages? Neil On 11 Dec 2014, at 15:02, Thomas Watson <[email protected]> wrote: No, Import-Package takes precedence over Require-Bundle. If a bundle is wired to a package with Import-Package then it will only delegate to the exported package for which the import-package requirement is wired to. The delegation stops there and the required-bundles are not searched. Tom From: Neil Bartlett <[email protected]> To: Equinox development mailing list <[email protected]> Date: 12/11/2014 08:45 AM Subject: Re: [equinox-dev] Exporting packages without a version Sent by: [email protected] It’s very unusual and wrong for a bundle to both import a package with Import-Package AND require the exporting bundle with Require-Bundle. Both of these requirements will be wired up independently, and will result in a highly inconsistent class space that is the reason for your LinkageErrors etc. Neil > On 11 Dec 2014, at 14:39, Dennis Hübner <[email protected]> wrote: > > Hi Neil, > thanks for your answer. > That means, that if a consumer bundle imports any packages but defines a requier-bundle with a version constraint to 2.8.0 it may became > classes loaded from a bundle with version 2.7.3? At least the console shows me that both versions are wired. > We also have LinkageErrors and ClassCastExceptions in eclipse with this scenario. > I also noticed that, this behavior depends on the installation order of bundles with the same version. > > >> Am 11.12.2014 um 15:27 schrieb Neil Bartlett <[email protected]>: >> >> This is a common misconception. There is no connection between bundle version and exported package versions. A bundle that imports using Import-Package will only care about the exported package versions, and a bundle that requires using Require-Bundle will only care about the Bundle-Version. >> >> Since Import-Package is the correct way to consume dependencies, it’s a significant problem that so many Eclipse bundles fail to version their packages. >> >> Neil >> >> >>> On 11 Dec 2014, at 14:08, Dennis Hübner <[email protected]> wrote: >>> >>> Hi equinox-dev team, >>> >>> I have a question regarding exporting an unversioned package. >>> If I look over the bundles in eclipse, the most of them (expect of some orbit bundles) exports packages without a version. >>> We do it likewise e.g.: >>> >>> Manifest-Version: 1.0 >>> Bundle-ManifestVersion: 2 >>> Bundle-Name: Xbase Runtime Library >>> Bundle-SymbolicName: org.eclipse.xtext.xbase.lib >>> Bundle-Version: 2.8.0.qualifier >>> Bundle-RequiredExecutionEnvironment: J2SE-1.5 >>> Export-Package: org.eclipse.xtend2.lib, >>> org.eclipse.xtext.xbase.lib, >>> org.eclipse.xtext.xbase.lib.internal;x-internal:=true, >>> org.eclipse.xtext.xbase.lib.util >>> >>> In an osqi container I see that this packages are exported with 0.0.0 it doesn’t care what the bundle-version is: >>> osgi> b 584 >>> org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584] >>> Id=584, Status=RESOLVED Data Root=/Users/dhuebner/Entwicklung/xtext-new/eclipse/configuration/org.eclipse.osgi/584/data >>> "No registered services." >>> No services in use. >>> Exported packages >>> org.eclipse.xtend2.lib; version="0.0.0"[exported] >>> org.eclipse.xtext.xbase.lib; version="0.0.0"[exported] >>> org.eclipse.xtext.xbase.lib.internal; version="0.0.0"[exported] >>> org.eclipse.xtext.xbase.lib.util; version="0.0.0"[exported] >>> Imported packages >>> com.google.common.annotations; version="15.0.0" <com.google.guava_15.0.0.v201403281430 [4]> >>> co >>> >>> osgi> b 626 >>> org.eclipse.xtext.xbase.lib_2.8.0.v201411111037 [626] >>> Id=626, Status=RESOLVED Data Root=/Users/dhuebner/Entwicklung/xtext-new/eclipse/configuration/org.eclipse.osgi/626/data >>> "No registered services." >>> No services in use. >>> Exported packages >>> org.eclipse.xtend2.lib; version="0.0.0"[exported] >>> org.eclipse.xtext.xbase.lib; version="0.0.0"[exported] >>> org.eclipse.xtext.xbase.lib.internal; version="0.0.0"[exported] >>> org.eclipse.xtext.xbase.lib.util; version="0.0.0"[exported] >>> Imported packages >>> com.google.common.annotations; version="15.0.0" <com.google.guava_15.0.0.v201403281430 [4]> >>> com.goo >>> >>> I thought, that if my bundle exports a package without a version, it means, that the version is the same as a Bundle-Version. But from what I see in the osgi console it seems that I’m wrong. >>> >>> osgi> b org.eclipse.xtend.lib >>> org.eclipse.xtend.lib_2.8.0.v201411111037 [544] >>> Id=544, Status=RESOLVED Data Root=/Users/dhuebner/Entwicklung/xtext-new/eclipse/configuration/org.eclipse.osgi/544/data >>> "No registered services." >>> No services in use. >>> Exported packages >>> org.eclipse.xtend.lib; version="0.0.0"[exported] >>> org.eclipse.xtend.lib.annotations; version="0.0.0"[exported] >>> Imported packages >>> com.google.common.annotations; version="15.0.0" <com.google.guava_15.0.0.v201403281430 [4]> >>> ... >>> org.eclipse.xtext.xbase.lib; version="0.0.0" <org.eclipse.xtext.xbase.lib_2.8.0.v201411111037 [626]> >>> org.eclipse.xtext.xbase.lib; version="0.0.0" <org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584]> >>> org.eclipse.xtext.xbase.lib.internal; version="0.0.0" <org.eclipse.xtext.xbase.lib_2.8.0.v201411111037 [626]> >>> org.eclipse.xtext.xbase.lib.internal; version="0.0.0" <org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584]> >>> org.eclipse.xtext.xbase.lib.util; version="0.0.0" <org.eclipse.xtext.xbase.lib_2.8.0.v201411111037 [626]> >>> org.eclipse.xtext.xbase.lib.util; version="0.0.0" <org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584]> >>> No fragment bundles >>> Required bundles >>> osgi.identity; osgi.identity="org.eclipse.xtext.xbase.lib"; type="osgi.bundle"; version:Version="2.8.0.v201411111037" >>> osgi.identity; osgi.identity="org.eclipse.xtend.lib.macro"; type="osgi.bundle"; version:Version="2.8.0.v201411111037" >>> >>> My question is, which package will be wired if an another bundle require (using Require-Bundle) an xbase.lib bundle with version constraint 2.8.0? >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ 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
_______________________________________________ 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
