Использование нативного артефакта Maven (nar) в веб-приложении - PullRequest
Новая
       30

Использование нативного артефакта Maven (nar) в веб-приложении

1 голос
/ 09 марта 2012

У меня есть собственная разделяемая библиотека, которая собирается и упаковывается с помощью плагина maven-nar. Это прекрасно работает и основывается на Linux / MacOSX / Windows. Я также определил библиотеку JNI, также созданную с использованием maven-nar, которая оборачивает общую библиотеку. Оба они создаются как артефакты NAR и требуют использования подключаемого модуля maven-nar.

Проблема возникает при объявлении зависимости от этих NAR от не-NAR-упакованного проекта. Плагин maven-nar никогда не вызывается. Только когда я изменяю упаковку проекта на NAR, включается плагин maven-nar. Это создает впечатление, что упаковка NAR должна быть заразной, чтобы работать, если есть зависимость NAR, тогда все вышестоящие проекты должны быть упакованы NAR. Это правильно или я что-то упустил?

Можно ли успешно использовать собственную веб-библиотеку и артефакты JNI, созданные с помощью плагина maven-nar, в веб-приложениях, т. Е. WAR? Если они могут быть использованы и развернуты в WAR, как это делается? В противном случае, является ли единственной возможностью вручную разместить собственные библиотеки в каком-либо месте в java.library.path на сервере приложений?

Вот фрагмент POM для проекта, который зависит от артефакта NAR JNI: 

  <?xml version="1.0" encoding="UTF-8"?>
  <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>thegroup</groupId>
    <artifactId>theparent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>../pom.xml</relativePath>
  </parent>

  <artifactId>thedependant</artifactId>
  <packaging>jar</packaging>
  <name>A nice name</name>

  ...

  <properties>
    <skipTests>true</skipTests>
  </properties>

  ...

  <build>
    <plugins>
       <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-nar-plugin</artifactId>
         <version>2.1-SNAPSHOT</version>
       </plugin>
    </plugins>
  </build>

  ...

  <dependencies>
    <dependency>
      <groupId>thegoup</groupId>
      <artifactId>theJNI</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>nar</type>
    </dependency>
  </dependencies>

  ...

</project>

1 Ответ

0 голосов
/ 09 марта 2012

Нет, или, по крайней мере, нелегко.

Если у вас есть JNI, вам нужно связываться с -Djava.library.path и, возможно, LD_LIBRARY_PATH / DYLD_LIBRARY_PATH / PATH, и всем, что должно произойти при запуске всего контейнера. Нет механизма распространения всего этого из войны на контейнер.

В полнофункциональной Java EE модель JCA была / предназначена для того, чтобы интегрировать нативный код в веб-приложения. Но типичные легкие контейнеры не поддерживают это.

Если ваш нативный код не имеет зависимостей от других разделяемых библиотек, и если вас не беспокоит конфликты нативного кода JVM (данный нативный класс может быть только в одном загрузчике классов), тогда ваша проблема - просто получение общих объектов в военный файл вообще.

http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html

- это один из подходов. Используйте плагин maven-dependency-plugin, чтобы поместить общие библиотеки в какой-либо каталог в $ {project.build.directory}, а затем выбрать их как «веб-ресурсы».

...