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 > >>> <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 > >> <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 > > <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 > <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
