felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Resolution for a bundle exporting and importing the same package
Date Fri, 19 Jun 2009 12:09:17 GMT
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.

On Fri, Jun 19, 2009 at 14:03, Felix Meschberger<fmeschbe@gmail.com> 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<fmeschbe@gmail.com> 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 ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message