felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: OBR, bundle fragments and native code
Date Mon, 31 Mar 2014 15:57:57 GMT
Sorry I meant osgi.native in the previous message... osgi.ee is another
capability entirely :-)

Both of these will be provided by the framework, i.e. by the system bundle.


On Mon, Mar 31, 2014 at 4:56 PM, Neil Bartlett <njbartlett@gmail.com> wrote:

> Okay so here's the thing... if you run this on any pre-R6 framework, then
> nothing provides this capability. And since R6 is not released, that means
> all of them.
>
> But you shouldn't have to explicitly require the osgi.ee capability. Even
> on R5 and earlier, the Bundle-NativeCode header creates an implicit
> requirement for the correct platform -- assuming you did not use a wildcard
> entry and got the format of this header correct (it is tricky).
>
> Regards,
> Neil
>
>
> On Mon, Mar 31, 2014 at 10:38 AM, Benoît Thiébault <thiebault@artenum.com>wrote:
>
>> Hi again,
>>
>> What bundle provides the osgi.native capability? When running Felix, I
>> have the following error:
>>
>> g! org.osgi.framework.BundleException: Unresolved constraint in bundle
>> org-myapp [42]: Unable to resolve 42.0: missing requirement [42.0]
>> org.myapp.native; (library=vtk) [caused by: Unable to resolve 43.0: missing
>> requirement [43.0] osgi.native;
>> (&(osgi.native.osname=MacOS)(os.native.processor=x86_64))]
>>
>> I’m using Felix 4.2.1 and I’m pretty sure I’m on a 64 bits Mac (Mavericks
>> 10.9.2)
>>
>> Kind regards
>> Ben
>>
>> Le 29 mars 2014 à 11:21, Neil Bartlett <njbartlett@gmail.com> a écrit :
>>
>> > You cannot do this with OBR. If you can use the R5 repository format,
>> along
>> > with the repoindex tool, then you can use Provide- and
>> Require-Capability
>> > headers to ensure the set of libraries you need is resolved. For example
>> > the fragment "org.example.nativelib.osx64" would provide something
>> custom
>> > like this:
>> >
>> >    Provide-Capability: myapp.native; library=com.example.nativelib
>> >
>> > and it would require the osgi.native capability to ensure it can only
>> > resolve on a single platform:
>> >
>> >    Require-Capability: osgi.native;
>> > filter:="(&(osgi.native.osname=MacOS)(os.native.processor=x86_64))"
>> >
>> > Now your core bundle just requires the myapp.native capability and the
>> > resolver will pick the right fragment for your runtime platform.
>> >
>> >
>> > On Sat, Mar 29, 2014 at 7:47 AM, Benoît Thiébault <
>> thiebault@artenum.com>wrote:
>> >
>> >> Hi everyone,
>> >>
>> >> I’m willing to simplify my application deployment and plan to use an
>> OBR.
>> >> On this OBR, I have deployed several bundles, including some containing
>> >> native code.
>> >>
>> >> I have a cross-platform bundle, say org.example.nativelib and one
>> fragment
>> >> for each platform:
>> >> - org.example.nativelib.linux64b
>> >> - org.example.nativelib.linux32b
>> >> - org.example.nativelib.win7-64b
>> >> - org.example.nativelib.osx64b
>> >> - etc.
>> >>
>> >> How can I be sure that when deploying org.example.nativelib from the
>> OBR,
>> >> the native fragment of the correct platform will be deployed?
>> >>
>> >> Thanks for your help
>> >>
>> >> Benoît
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>>
>> --
>> Dr Benoît Thiébault
>> Project Manager
>>
>>   Artenum Toulouse - Science & Groupware
>>   http://www.artenum.com
>>
>>       Bâtiment Calfocenter
>>       10, rue Marguerite-Long
>>       31320 Castanet-Tolosan
>>       France
>>       Phone: +33 (0)5 82 95 19 00
>>
>>
>>
>

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