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 14:28:13 GMT
On Fri, Jun 19, 2009 at 15:42, Richard S. Hall<heavy@ungoverned.org> wrote:
> On 6/19/09 7:57 AM, Guillaume Nodet wrote:
>>
>> I think we have two different use case for a bundle importing /
>> exporting the same package.
>>
>> I think the first use case is when you have two different
>> implementation of a given service.  If each service bundles its api,
>> you'll end up with multiple bundles exporting the same package with
>> the same version.   In such a case, I think it makes sense to choose
>> to wire to an external bundle.
>>
>> The second use case is when you have two different packages exported
>> with different versions.   I think in such a case, felix should choose
>> the internal package rather than an external.
>>
>
> Not sure I understand this second case.

This is the use case I expressed in my first email, when you have two
bundles, each one exporting its own different version of package a.
This is a usual case when you simply deploy the same library in two
different versions.

Let's assume that those libraries follow the usual best practices (at
least those I know about, but correct me if i'm wrong).
I create a library and use bnd to generate the manifest.
So I use the following instrutions:

    <Import-Package>*</Import-Package>
    <Export-Package>foo;version="1.0"<Export-Package>
    <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>

This generates the following headers:
  Import-Package: foo;version="[1.0,2.0)"
  Export-Package: foo;version="1.0"

If I create a 1.1 version of the same library using the same rules,
the headers will become:
  Import-Package: foo;version="[1.1,2.0)"
  Export-Package: foo;version="1.1"

Now, it means if i have already installed the 1.1 version of my
library, i won't be able to use the 1.0 version at all, because the
package will not be exported.
I would understand that the bundle importing the library would always
be wired to the 1.1 version unless it has a specific constraint to
1.0, but this constraint could not even by fullfilled because the
older package is completely hidden.

Maybe the problem come from a misconception, and that importing the
package you export is actually not a good practice when this package
is more an implementation package rather than an api package.   Or
maybe the problem is that you need to always import the exact same
version (without range) that you export.
In all cases, I'd like the maven bundle plugin to do it the right way
by default and avoid users running into problems.  I guess I just need
to understand what is the right way ;-)

>
> -> richard
>
>> On Fri, Jun 19, 2009 at 13:59, Richard S. Hall<heavy@ungoverned.org>
>>  wrote:
>>
>>>
>>> The seems fairly clear on this. A version like "1.0" is a range from 1.0
>>> to
>>> infinity. All things being equal, the resolver is supposed to select the
>>> highest matching version, which is what happens here.
>>>
>>> There is some wiggle room since the spec does allow the framework to
>>> choose
>>> when a bundle should export or import in this case, but favoring import
>>> seems to make sense to reduce the number of inconsistent class spaces.
>>>
>>> Otherwise I would say the bundle metadata is in error.
>>>
>>> ->  richard
>>>
>>> On 06/19/2009 07:39 AM, Guillaume Nodet wrote:
>>>
>>>>
>>>> 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 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