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 11:57:45 GMT
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.

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