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 <[email protected]> wrote: > > > On 10/03/14 11:05, Alexander Broekhuis wrote: > >> Hi >> >> >> 2014-03-06 22:36 GMT+01:00 Ferry Huberts <[email protected]>: >> >> >>> >>> 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. Greetings, Pepijn
