celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Multiple library support and code sharing
Date Tue, 18 Mar 2014 08:40:32 GMT
Hi All,

Sorry for the late reaction, but I looked at CELIX-111 and CELIX-112 and I
think this is good approach. I am not to happy about the requirement for
specifying the libraries in order to get it working, but this is something
we can improve a later stage.

On Sat, Mar 15, 2014 at 8:23 PM, Ferry Huberts <mailings@hupie.com> wrote:

> On 10/03/14 11:05, Alexander Broekhuis wrote:
>> Hi
>> 2014-03-06 22:36 GMT+01:00 Ferry Huberts <mailings@hupie.com>:
>>> On 06/03/14 22:23, Mike van Dongen wrote:
>>>  Hi Alexander,
>>>> This might also be a solution to a problem I stumbled upon when using
>>>> Celix with Apache ACE.
>>>> The problem is that Celix bundles lack compatibility between different
>>>> platforms and architectures.For example, bundles compiled on Linux x86
>>>> can
>>>> (for obvious reasons) not be used on Linux x86-64, or on Mac OS/Windows
>>>> for
>>>> that matter.
>>>> I don't know if others consider this to be a problem/useful feature,
>>>> but IMHO it's something to discuss as it would mean supporting multiple
>>>> libraries in a bundle.
>>>  While this is not yet on the radar for Celix, it is definitely something
>> that is part of Native-OSGi. At this moment the Native OSGi refers to
>> Executions Environments as a possible solution, in that case a bundle
>> would
>> be for a specific platform, and the execution environment would be a
>> requirement for the platform.
>> In our opinion this is a better match, the bundles are kept small
>> (interesting for embedding) and platform specific (easier to add a
>> different platform for a component as new bundle later), the environment
>> declares what platform. (where platform can be a combination of
>> information
>> which still has to be properly defined, eg architecture, libc, etc).
>>> Either that or adding the corresponding Require-Capability header
>>> Also worth a mention, there might be other Req-Cap's needed: for example
>>> one for the c library version. A library compiled on Fedora 20 will not
>>> work on Debian Wheezy because of the c library version difference.
>>> Something to consider.. :-)
>> Req-Cap seems interesting as well, although I don't think it should be
>> used
>> for environment information. IMHO Req-Cap specify additional
>> dependencies/relations between bundles, not from bundles to the
>> environment. Having said that, I might be wrong, and perhaps with a
>> different view Req-Cap can as well be usable for the environment, so feel
>> free to elaborate and shoot at this :).
> Actually, Req-Cap is universal and a bundle DOES have (at least 1,
> possibly more) a requirement to its environment. In bnd we actually
> generate these by default: a bundle compiled for Java 1.7 will get a
> Requirement for an execution environment that supports 1.7....
> This specific example prevents errors like 'compile on 1.7, deploy on
> 1.6'. Doing that will make the resolver complain ;-)
> So in the Celix case, this example translates into a Req on libc version
> <your libc version here>. :-)

Is specifying the libc version enough? I expect we also need to specify
which architecture (e.g. x86_64) and OS (e.g Mac). But I do think this is a
nice feature, especially in combination with Apache ACE and multiple
(heterogeneous) targets.


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