[jitsi-dev] Packaging of native libraries


#1

Dear developers,

We're currently distributing the binaries of native/JNI libraries
separately from their respective Java classes/jars. With the
introduction of Maven, Maven is going to be responsible for the
availability of the jars so we need to decide how to handle the
respective native binaries.

Do we want to package these together i.e. have the native/JNI library
binaries packaged into the respective jars as resources? Since there
are multiple supported operating systems, a jar will end up containing
all OS-specific binaries of a respective JNI library.

Otherwise, I could try to figure out whether it's possible to preserve
the status quo but I'm not very hopeful on that subject right now.

Best regards,
Lyubo Marinov


#2

Hey

We're currently distributing the binaries of native/JNI libraries
separately from their respective Java classes/jars. With the
introduction of Maven, Maven is going to be responsible for the
availability of the jars so we need to decide how to handle the
respective native binaries.

Do we want to package these together i.e. have the native/JNI library
binaries packaged into the respective jars as resources? Since there
are multiple supported operating systems, a jar will end up containing
all OS-specific binaries of a respective JNI library.

Otherwise, I could try to figure out whether it's possible to preserve
the status quo but I'm not very hopeful on that subject right now.

Go the Maven way. It should make e.g. libjitsi usable without having to worry about correctly setting up library paths. As far as it concerns Linux distros, e.g. our Debian build, the build system should be able to exclude the "foreign" natives.

Best regards,
Lyubo Marinov

Cheers,
Ingo


#3

Dear Ingo,

Thank you very much for your invaluable help!

Go the Maven way. It should make e.g. libjitsi usable without having to worry about correctly setting up library paths. As far as it concerns Linux distros, e.g. our Debian build, the build system should be able to exclude the "foreign" natives.

I'd like to make sure that we're on the same page here because I'm not
sure what the Maven way is with respect to JNI libraries. Could you
please clarify? Is it one of the following?

1. Keep the JNI binaries in the GitHub repository and package them as
resources inside the jar? (I guess we'll leave the subject of keeping
JNI binary files in the source repository for later.)
2. Use a Maven plugin to actually build the native libraries from
source? (That I'm currently hesitant about.)

Best regards,
Lyubo Marinov

···

2015-07-06 14:44 GMT-05:00 Ingo Bauersachs <ingo@jitsi.org>:


#4

Thank you very much for your invaluable help!

You're very welcome, and please let me know if I can help you other than just commenting on the list.

Go the Maven way. It should make e.g. libjitsi usable without having to
worry about correctly setting up library paths. As far as it concerns Linux
distros, e.g. our Debian build, the build system should be able to exclude
the "foreign" natives.

I'd like to make sure that we're on the same page here because I'm not
sure what the Maven way is with respect to JNI libraries. Could you
please clarify? Is it one of the following?

Sorry, what I meant with that was to actually include the JNI binaries in the jar. Not how they are built. So: (1).

1. Keep the JNI binaries in the GitHub repository and package them as
resources inside the jar? (I guess we'll leave the subject of keeping
JNI binary files in the source repository for later.)
2. Use a Maven plugin to actually build the native libraries from
source? (That I'm currently hesitant about.)

I'd appreciate it if we'd at some point could move to (2), but that time hasn't come yet.

Best regards,
Lyubo Marinov

Ingo

···

2015-07-06 14:44 GMT-05:00 Ingo Bauersachs <ingo@jitsi.org>: