On 29/03/14 10:35, Beno�t Thi�bault wrote:
Hi and thanks for your answer.
Putting everything in one bundle doesn't sound very modular... I would like
each deployment to include only what is necessary for it to work... Isn't it
possible?
How is it not modular?
I'd say it's very modular because the platform specific parts that your
bundle needs to work are included. Which makes your bundle deployable on
all platforms.
Right now your deployment needs all kinds of special things to account
for the platforms, you have different deployments...
I'd that _that_ is not very modular.
There are more perspectives on issues like these.
I'd go with simplicity every time. Do not optimise for
size/speed/whatever until you have simplicity.
A best-practice is to have a bundle that includes all native libs and
just implements an abstracted API, with the java op top of the libs as
thin as possible. Then have a generic bundle use that first bundle (as a
service)
Le 29 mars 2014 10:27, Ferry Huberts <[email protected]> a écrit :
On 29/03/14 08:47, Benoît Thiébault 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?
Include them in the bundle itself.
An example from my jnotify project:
Bundle-NativeCode: lib/linux/i686/libjnotify.so;osname=Linux;processor=x86,\
lib/linux/x86_64/libjnotify.so;osname=Linux;processor=x86-64
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
