Hi Neil,
would „uses“ clause/directive relax the problem a bit?

Regards,
Dennis.

> Am 11.12.2014 um 16:08 schrieb Neil Bartlett <[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] 
>> <mailto:[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] 
>> <mailto:[email protected]>>
>> To:        Equinox development mailing list <[email protected] 
>> <mailto:[email protected]>>
>> Date:        12/11/2014 08:45 AM
>> Subject:        Re: [equinox-dev] Exporting packages without a version
>> Sent by:        [email protected] 
>> <mailto:[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] 
>> > <mailto:[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] 
>> >> <mailto:[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] 
>> >>> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
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

Reply via email to