Maven и библиотека JOGL?

Если вы внимательно прочитаете его, то увидите, что одним из решений для использования библиотек JNI является объединение их в JAR-архитектуру, чтобы вы могли зависеть от них, как и от любых других зависимостей с точки зрения Maven. На самом деле, так упакована JOGL версия 1.1.1 в http://download.java.net/maven/2/net/java/dev/jogl/, есть один артефакт JAR с классами Java и несколько артефактов JAR, специфичных для архитектуры, с родными библиотеками.

Библиотека JNI, заархивированная в банке

Решение, которое я в итоге использовал, заключалось в том, чтобы хранить скомпилированную библиотеку jni в jar рядом с файлами классов.

Это означает либо кросс-компиляцию для все возможные архитектуры, или более просто, имея другую банку для каждая архитектура. Эта последняя подходит довольно хорошо с нашей установкой - где почти все наши машины Linux-i386, с небольшим выигрышем32 коробки.

К сожалению 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 {
 статическое электричество
 пытаться
 NativeLoader.loadLibrary("sqrt");
 } catch (Throwable e) {
 e.printStackTrace();
 System.exit(1);
 }
 }
 /* ... тело класса... */
}

Сейчас мы должны быть на том этапе, когда наши тесты на смешение работают от maven; a mvn тест должен сработать! Он также должен работать Прекрасно из IDE.

Теперь, чтобы ответить на ваши вопросы, как:

Автоматически загрузить, при необходимости, специфичный для операционной системы zip-файл JOGL отсюда (содержит 4 jar-файла и некоторые файлы родной библиотеки (.so/.dll)); или зависит от проекта Maven, который является оберткой одного из файлов.

К сожалению, JOGL 2.0 jars не доступны в репозитории Maven java.net, поэтому вам придется разобраться с этим и либо сделать их доступными в частном репозитории, либо установить их вручную в локальном репозитории каждого разработчика. Для этого используйте mvn install:install-file, как описано в Руководстве по установке сторонних JAR (а не mvn deployment:deploymenty-file, как это было сделано, эта цель используется для установки артефактов в удаленный репозиторий). Лично я бы загрузил JOGL 2.0 ZIP-файлы с URL, который вы предоставили, упаковал его так же, как и JOGL 1.1.1 (один Java JAR и несколько специфических JAR для родных библиотек) и установил бы JAR-файлы в каждый локальный репозиторий на данный момент. Затем, объявите стандартную зависимость от артефакта Java и, действительно, используйте профили для специфических для архитектуры зависимостей. Что-то вроде этого:

<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-файлов, и вам не придется их распаковывать ни во время разработки, ни для распространения вашего проекта. Для дистрибутива вам просто нужно будет создать банку с зависимостями. Это можно сделать с помощью maven-assembly-plugin. Смотрите, например, этот ответ .