Discussion :

[CorbAddict]

Bonjour,

J'ai un projet Java géré sous Maven, auquel je doit ajouter un outil de gestion de licence (RLM) qui a malheureusement la mauvaise idée d'utiliser une librairie native (en C)...
J'ai a disposition différentes versions compilées de cette librairie selon la plateforme cible (linux 32/64 bits, windows 32bits...).

Je cherche un moyen de gérer une dépendance vers ces librairies, et idéalement un moyen simple pour faire charger en Java la librairie qui convient selon la plateforme.

Je suis en train de regarder le plugin maven-nar-plugin. Il paraît intéressant, mais me semble plutôt fait pour compiler et packager du code natif. Or dans mon cas, il est déjà compilé...
De plus ce plugin est en version SNAPSHOT et je n'ai pas trouvé de roadmap indiquant une date prévue pour une version release.

L'un de vous aurait-il utilisé ce plugin dans un cas similaire au mien (si oui comment) ?
Ou auriez-vous d'autres suggestions pour mon problème ?

Merci de votre aide!

[-gma-]

Bonjour,

As tu regardé JNI ou JNA ?

[CorbAddict]

Bonjour,

As tu regardé JNI ou JNA ?

Merci pour ta réponse, mais RLM fournit déjà une API Java faisant appel à leur librairie native (via du JNI).
Mon problème n'est donc pas l'utilisation de ce code natif en Java, mais uniquement la manière de gérer une dépendance vers ces librairies natives avec Maven (et si au passage un tel plugin me configure le java.library.path pour pointer vers un répertoire contenant la version correcte de la librairie selon la plateforme, ce serait top ).
Je n'ai pas vu de référence à un plugin Maven pour JNI ou JNA dans ton lien.

[-gma-]

En JNI le nom du fichier de la bibliothèque peut suffire si on utilise System.loadLibrary(libName) où libName est le nom sans l'extension. La JVM ira chercher un fichier avec la bonne extension selon la plateforme (.dll, .so, etc) dans le java.library.path (la valeur par défaut peut suffire selon comment l'appli s'installe).

Sinon si on utilise System.load(pathName) alors pathName doit être le chemin complet vers le fichier de la biliothèque (avec répertoires et extensions). A ce moment là, un simple fichier properties avec le chemin dépendant de l'OS est suffisant mais ça n'a plus aucun rapport avec JNI, d'un point de vu Maven du moins.
Pareil si on passe le pathName en paramètre ou en propriété système à l'application, cela va dépendre de la façon dont on lance l'appli et donc de l'OS.

Tu peux donc peut être réorienter ta recherche vers un plugin qui gère le packaging ou le lancement des applications si tu tiens à faire ça avec Maven.

[CorbAddict]

A ce moment là, un simple fichier properties avec le chemin dépendant de l'OS est suffisant mais ça n'a plus aucun rapport avec JNI, d'un point de vu Maven du moins.
Pareil si on passe le pathName en paramètre ou en propriété système à l'application, cela va dépendre de la façon dont on lance l'appli et donc de l'OS.

En fait le maven-nar-plugin à l'air de résoudre ce problème en générant un bout de code Java qui va charger la bonne librairie au bon endroit (un sous-répertoire du repo Maven local) en fonction de la platforme (cf. la FAQ de maven-nar-plugin)
Cette solution me semble pratique et évite d'avoir à configurer soi-même le path vers la librairie.

Tu peux donc peut être réorienter ta recherche vers un plugin qui gère le packaging...

Oui, c'est exactement ce que je cherche.
Le maven-nar-plugin à l'air de convenir sur le papier, mais il est en cours de développement, la doc est sommaire et parfois fausse (d'après mes 1ers tests) et il fait beaucoup de choses dont je n'ai pas besoin (compilation et link C/C++).
Quelqu'un a-t-il une solution alternative à me suggérer ?
Ou des conseils d'utilisation de maven-nar-plugin pour mon cas ?