При работе с JNI и Maven Проекты с JNI равны , с которых следует начинать . Он охватывает гораздо больше, чем ваша текущая проблема (которая «просто» использует библиотеку, которая опирается на JNI и нативные библиотеки), но тот, кто может сделать больше, может сделать меньше.
Если вы внимательно прочитаете его, вы увидите, что одним из решений использования библиотек JNI является объединение их в JAR-файлы, специфичные для архитектуры, чтобы вы могли зависеть от них, как и от любой другой зависимости с точки зрения Maven. Именно так JOGL версии 1.1.1 упакован в http://download.java.net/maven/2/net/java/dev/jogl/,, есть один JAR-артефакт с классами Java и несколько архитектурно-специфических JAR-артефактов с собственными библиотеками.
Библиотека JNI, заархивированная в банке
Решение, которое я использовал, заключалось в том, чтобы
сохранить скомпилированную библиотеку jni в
банка с файлами классов.
Это означает либо кросс-компиляцию для
все возможные архитектуры или более
просто имея другую баночку для
каждая архитектура. Этот последний подходит
довольно хорошо с нашей настройкой - где
почти все наши машины
Linux-i386, с небольшим количеством win32
коробки.
К сожалению System.load() не может справиться с
загрузка библиотек из банки,
поэтому нам понадобится обычай
загрузчик, который извлекает библиотеку в
временный файл во время выполнения; это
очевидно достижимо, однако.
Тогда, как объяснено, идея состоит в том, чтобы использовать собственный загрузчик библиотеки для загрузки собственной библиотеки. Хорошей новостью является то, что такой загрузчик «предоставляется», как описано ниже.
Библиотека загрузчика
Теперь у нас есть библиотека JNI на
путь к классу, поэтому нам нужен способ
загружаю это. Я создал отдельный
проект, который извлек бы JNI
библиотеки из пути к классам, затем
загрузить их. Найдите это в
http://opensource.mxtelecom.com/maven/repo/com/wapmx/native/mx-native-loader/1.2/.
Это добавляется как зависимость к
Пом, очевидно.
Чтобы использовать это, позвоните
com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(libname).
Больше информации в Javadoc для
NativeLoader.
Я обычно предпочитаю оборачивать такие вещи
в блоке try / catch, следующим образом:
public class Sqrt {
static {
try {
NativeLoader.loadLibrary("sqrt");
} catch (Throwable e) {
e.printStackTrace();
System.exit(1);
}
}
/* ... class body ... */
}
Теперь мы должны быть в точке, где
наши тесты Junit работают от Maven; мвн
тест должен работать! Должно также работать
штраф из IDE.
Теперь, чтобы ответить на ваши вопросы, как:
Автоматически загружать, если необходимо, отсюда zip-файл JOGL для конкретной операционной системы (содержит 4 jar-файла и некоторые собственные файлы библиотеки (.so / .dll)); или зависит от проекта Maven, являющегося оболочкой одного из файлов.
К сожалению, jog-файлы JOGL 2.0 недоступны в репозитории Maven java.net, поэтому вам придется с этим справиться и либо сделать их доступными в частном репозитории, либо установить их вручную в локальном репозитории каждого разработчика. Для этого используйте mvn install:install-file, как описано в Руководстве по установке сторонних JAR (а не mvn deploy:deploy-file, как вы это делали, эта цель используется для установки артефактов в удаленный репозиторий).
Лично я бы скачал ZIP-файлы JOGL 2.0 с предоставленного вами URL-адреса , упаковал его, как они делали с JOGL 1.1.1 (один JAR-файл Java и несколько специальных JAR-файлов для собственных библиотек), и установил JAR-файлы каждый локальный репозиторий на данный момент. Затем объявите стандартную зависимость от артефакта Java и, на самом деле, используйте profile для зависимости от конкретной архитектуры. Примерно так:
<project>
...
<dependencies>
<dependency>
<groupId>net.java.dev.jogl</groupId>
<artifactId>jogl</artifactId>
<version>2.0-beta10</version>
</dependency>
...
</dependencies>
...
<profiles>
<profile>
<id>linux-i586</id>
<activation>
<os>
<arch>i386</arch>
<family>unix</family>
<name>linux</name>
</os>
</activation>
<dependencies>
<dependency>
<groupId>net.java.dev.jogl.jogl-linux-i586</groupId>
<artifactId>jogl-linux-i586</artifactId>
<version>2.0-beta10</version>
</dependency>
</dependencies>
</profile>
...
</profiles>
...
</project>
Не забудьте добавить хранилище, необходимое для загрузчика пользовательской библиотеки, и зависимость:
<project>
<repositories>
<repository>
<id>opensource.mxtelecom.com</id>
<url>http://opensource.mxtelecom.com/maven/repo</url>
</repository>
...
<repositories>
...
<dependencies>
<dependency>
<groupId>com.wapmx.native</groupId>
<artifactId>mx-native-loader</artifactId>
<version>1.2</version>
</dependency>
...
</dependencies>
...
</project>
Относительно второй части вашего вопроса:
Распакуйте этот zip-файл соответствующим образом, чтобы (...)
Как я объяснил, вы на самом деле будете зависеть не от ZIP-файлов, а от JAR-файлов, и вам не нужно будет распаковывать их ни во время разработки, ни для распространения вашего проекта. Для распространения вам просто нужно создать jar, включающий зависимости. Это можно сделать с помощью плагина maven-assembly-plugin. См. этот ответ , например, для более подробной информации об этом.