felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Resolution for a bundle exporting and importing the same package
Date Fri, 19 Jun 2009 13:46:56 GMT
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<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 ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>            
>>>
>>>        
>
>
>
>    

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message