Choose a build system

[tresf]

@bmhm has been very helpful in giving us some examples on how to create a JNI project with Maven with a working proof-of-concept here: https://github.com/bmhm/native-example

• Decide if the project use Maven, Gradle or something else
  • Note, some early work for Maven support is available in 2.8.1-experimental branch, authored kindly by @vogt31337
• Decide if we keep cmake or do we leverage Maven's native build capabilities directly
  • // edit by @bmhm: As discussed, we stick to cmake because of MacOS builds

Note, the temporarily cmake branch has a boilerplate for native and cross-compiling. This will be merged back into mainline once the above decisions are made.

Further TODO for the maven-cmake-branch:

• move the java parts to src/main/java
• restructure into submodules, so there can be multiple build jobs (one for each platform).
• find and replace hardcoded occurrences of linux_64.
• ask @tresf or @woodrowbarlow how to fix that UnsatisfiedLinkError in my previous comment.

[bmarwell]

As discussed, I based a new example on the existing cmake branch authored by @woodrowbarlow. You can find it here:
https://github.com/java-native/java-simple-serial-connector/tree/maven-cmake

Caveats

I added a test, but it crashes with java.lang.UnsatisfiedLinkError: jssc.SerialNativeInterface.getNativeLibraryVersion()Ljava/lang/String;

Although the method exists:

$ nm -D target/classes/META-INF/lib/linux_64/libjssc.so | grep "Java_.*getNativeLibr"
0000000000005c20 T _Z55Java_jssc_SerialNativeInterface_getNativeLibraryVersionP7JNIEnv_P8_jobject

Generated files

I deleted all generated files (.so, .dll, .h, etc.).
I found that there was a manually added line in the .h file by @scream3r:

#undef jSSC_NATIVE_LIB_VERSION
#define jSSC_NATIVE_LIB_VERSION "2.8"

Meaning it wasn't truly generated after all.

Directory structure

I converted some directories to the maven standard directory layout. If you haven't seen it before, please take a quick look.

Built files go to target/ and get removed on a clean build (mvn clean install).

JDK compatiblity

I set some properties to force java 1.6, as requested. javah does not exist in JDK 9 updwards, so I had to add a profile where the maven compiler plugin does this job instead.

cmake invocation

cmake can only generate headers from jar files, which doesn't help us very much. We had to repackage the jar. So I decided to let maven do all the stuff it can do nicely first (executing cmake-generate, compiling, generating headers), then executing cmake-compile. This seems to work nicely.

native-lib-loader

I started using https://github.com/scijava/native-lib-loader because it has some sane fail-safes and is well tested.

cmake will put it's files to target/classes/META-INF/lib/<platform>/libjssc.<ext> accordingly, so native-lib-loader can find them.

[tresf]

• move the java parts to src/main/java

^-- This has FIXMES in the code. We'll do this eventually but we'd like to move over open PRs before we do any major refactoring. This is a followup task.

restructure into submodules, so there can be multiple build jobs (one for each platform).

This concern is still valid, but has less to do with the build system and more to do with how we store the binaries.

• Choose a build system

We've chosen maven for now. WIP is happening in a few branches until they're merged to master. For now, see #14 and #18. They should be merged to master as soon as humanly possible. 😄