Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Exporting packages without a version

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

Regards,
Dennis.

Am 11.12.2014 um 16:08 schrieb Neil Bartlett <njbartlett@xxxxxxxxx>:

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 <tjwatson@xxxxxxxxxx> 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 <njbartlett@xxxxxxxxx>
To:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:        12/11/2014 08:45 AM
Subject:        Re: [equinox-dev] Exporting packages without a version
Sent by:        equinox-dev-bounces@xxxxxxxxxxx




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 <dennis.huebner@xxxxxxxxx> 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 <njbartlett@xxxxxxxxx>:
>>
>> 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 <dennis.huebner@xxxxxxxxx> 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
>>> equinox-dev@xxxxxxxxxxx
>>> 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
>> equinox-dev@xxxxxxxxxxx
>> 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
> equinox-dev@xxxxxxxxxxx
> 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
equinox-dev@xxxxxxxxxxx
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
equinox-dev@xxxxxxxxxxx
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
equinox-dev@xxxxxxxxxxx
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


Back to the top