Re: [equinox-dev] Exporting packages without a version

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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