JavaCPP-based platform bindings (LibreMidiAccess, RtMidiAccess) fail to resolve jars to the native bindings

[atsushieno]

It seems that apps (at least Compose Desktop apps like ktmidi-ci-tool) that depend on the latest JavaCPP based bindings fail to resolve the Jars that contain native libraries (e.g. libremidi-javacpp-linux-x86_64.jar) and thus fails at run time:

> Task :ktmidi-ci-tool:run
Warning: Version of dev.atsushieno:libremidi_javacpp could not be found.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no jnilibremidi in java.library.path: /Users/atsushi/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
Version of dev.atsushieno:libremidi_javacpp could not be found.

There seems some issue around packaging and/or package resolution with gradle-javacpp. The Gradle plugin org.bytedeco.gradle-javacpp-platform, along with api(libs.libremidi.javacpp.platform) (versions in libs.versions.toml), should transform the api() reference to the native library bindings, but it is somehow not triggered.

There are some findings:

• If the bindings (libremidi-javacpp or rtmidi-javacpp) were put in the local Maven repository (via publishToMavenLocal), the Compose Desktop apps successfully contain the native bindings.
• Package files are successfully published at least at libremidi-javacpp v0.1.4.
• input-sample and player-sample work on the IDE too, IF libremidi-javacpp is published locally.

confirmed at: c24dc1a

[rkechols]

I've opened an issue with gradle-javacpp to see if anyone there can help diagnose/fix the issue:
bytedeco/gradle-javacpp#33

[rkechols]

In the meantime, my best guess is that the problem is that the platform-specific artifacts are published under libremidi-javacpp (here), rather than with the -platform suffix here.

[atsushieno]

I think I'm following what javacpp-presets does, for example:

• https://repo1.maven.org/maven2/org/bytedeco/flycapture/2.13.3.31-1.5.9/
• https://repo1.maven.org/maven2/org/bytedeco/flycapture-platform/2.13.3.31-1.5.9/

[atsushieno]

I wrote a bit more about it at atsushieno/libremidi-javacpp@f50ebff

[atsushieno]

There seems no single working example of gradle-javacpp based library that was successfully published to Maven Central and proved its usefulness yet. We might have to give up current build setup.

At this state, there are some alternative options I can think of:

• Rewrite libremidi-javacpp to dump Gradle and use Maven instead: if the problem is only publishing package, then it would be the remedy. But if there is any problem in javacpp-gradle-platform too, there is no escape hatch.
• Get libremidi-panama working: there are many steps to go over. panama jextract is not as user-friendly as javacpp and we have to hack library loader, packaging integration, and so on. Also libremidi-panama itself is not known to work. And Panama API itself is not stable yet.
• switch to JNA. But since JNAerator is not maintained anymore, we might have to manually create API bindings. Then the same loader and packager issues are there. Not sure how long JNA will be maintained in favor of Panama.

Although in the meantime, it is very likely that submoduling libremidi-javacpp, build and perform publishToMavenLocal would fix local issues as well as app packaging issues.