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
To: Equinox development mailing list
Hi Neil,
would „uses“ clause/directive relax the problem a bit?
Regards,
Dennis.
> Am 11.12.2014 um 16:08 schrieb Neil Bartlett :
>
> 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 thr
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 importe
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
Thank’s a lot to all for your answers!
Now I know what goes wrong.
@Thomas As you said our org.eclipse.xtend.lib.macro bundle still has a version
constraint set to > 2.7.0.
Loaded 2.7.3 xbase.lib and reexported the dependency. :(
That seems to be a cause of the strange wiring.
I will try to summ
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 et
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 Linka
To be clear, exporting a package without a version is against best
practices of OSGi. I know Eclipse projects (including some bundles in
Equinox) do not follow this best practice. That is largely due to the
historical way most Eclipse projects declare their dependencies (at the
bundle level u
equinox-dev-boun...@eclipse.org wrote on 2014/12/11 09:08:19:
> From: Dennis Hübner
> To: equinox-dev@eclipse.org
> Date: 2014/12/11 09:10
> Subject: [equinox-dev] Exporting packages without a version
> Sent by: equinox-dev-boun...@eclipse.org
>
> Hi equinox-dev team,
>
> I have a question rega
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.
Si
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
11 matches
Mail list logo