felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Resolution for a bundle exporting and importing the same package
Date Fri, 19 Jun 2009 11:49:06 GMT

Guillaume Nodet schrieb:
> Let's say we have two bundles
> foo-1.0:
> Export-Package: a;version="1.0"
> Import-Package: a;version="1.0"
> foo-2.0:
> Export-Package: a;version="2.0"
> Import-Package: a;version="2.0"
> In felix (trunk), if you install foo-2.0, then foo-1.0, you end up with:
> foo-2.0:
> Export-Package: a;version="2.0"
> foo-1.0:
> Import-Package: a;version="2.0"

This is correct as the resolution specification in Section 3.7,
Resolution of the core spec (right at the end of that section):

The following list defines the preferences, if multiple choices are
in order of decreasing priority:
  * A resolved exporter must be preferred over an unresolved exporter.
  * An exporter with a higher version is preferred over an exporter with
    a lower version.
  * An exporter with a lower bundle ID is preferred over a bundle with a
    higher ID.

This, since foo-2.0 exports a more recent version, both should import
that version.

To prvent foo-1.0 from importing a;version="2.0" the import would have
to be written as a version range excluding version 2.0:

   Import-Package: a;version="[1.0,2.0)"

This would effectively result in foo-1.0 and foo-2.0 using incompatible
classes and not be able to exchange objects from the "a" package.

(But you might want to have this ...)

There is catch, tough: Consider foo-1.0 installed and started. Now you
install and start foo-2.0. Now, foo-1.0 is wired to its own export and
foo-2.0 is wired to its own export and thus both bundles do *not* share
the a package.... If you then refresh foo-1.0 (with above import
declaration) it will wire to foo-2.0's export.... [You might call this a
corner case, but I am currently fighting such a case looking for a


> This really looks ackward (and will mostly lead to failures if the
> major versions are not really compatible), though I haven't seen
> anything in the core spec to forbid this.
> Section 3.7 says that the resolution for foo-1.0 should either choose
> an external package (which is what done here) or an internal package.
> Equinox seems to handle it using an internal package.
> What would you think about changing the resolution algorithm so that
> it try to use an internal package instead of an external package if
> all the constraints are met ?

View raw message