On 6/19/09 8:09 AM, Guillaume Nodet wrote:
As I said, I know this is correct, but the spec says the resolver has
two alternatives.
What I want is to discuss why we would not choose the other way, which
would *also* be right.
It is an easier policy to select the highest matching version to create
fewer class spaces.
We couldn't have an general approach of favoring the export, because
this would always create a new class space. As a result, we would have
to come up with some nuanced policy of when to favor the internal export
over the import, including how this relates to specified version ranges.
And I am sure no matter what we choose, it won't make everyone happy and
we won't be much better off than we are now.
Those are my initial thoughts, but I am happy to have the discussion.
-> richard
On Fri, Jun 19, 2009 at 14:03, Felix Meschberger<[email protected]> wrote:
Hi,
Guillaume Nodet schrieb:
Using a version range does not really solve the problem.
What if you have:
foo-1.0:
Export-Package: a;version="1.0"
Import-Package: a;version="[1.0,2.0)"
foo-1.1:
Export-Package: a;version="1.1"
Import-Package: a;version="[1.1,2.0)"
The exact same problem will happen.
Yes, and is correct for the exact same reason ;-)
Maybe the only way to circumvent this is to use [1.0,1.0] as you alredy
stipulated.
Regards
Felix
On Fri, Jun 19, 2009 at 13:49, Felix Meschberger<[email protected]> wrote:
Hi,
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
possible,
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
solution].
Regards
Felix
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 ?
