在Web应用程序中使用本机Maven工件(nar)

在Web应用程序中使用本机Maven工件(nar)

问题描述:

我有一个使用maven-nar插件构建和打包的本地共享库.这很好用,并且可以在Linux/MacOSX/Windows上构建.我还定义了一个JNI库,该库也使用maven-nar构建,用于包装共享库.这两个都是作为NAR工件生成的,并且需要使用maven-nar插件才能使用.

I have a native shared library that is built and packaged using the maven-nar plugin. This works great and builds on Linux/MacOSX/Windows. I've also defined a JNI library, also built using maven-nar, that wraps the shared library. Both of these are produced as NAR artifacts and require the maven-nar plugin in order to be used.

当从非NAR打包项目中声明对这些NAR的依赖关系时,就会出现问题. maven-nar插件似乎从未被调用.只有当我将项目的包装更改为NAR时,maven-nar插件才会启动.这使得NAR包装似乎需要具有传染性才能起作用,如果存在NAR依赖性,则所有上游项目都需要进行NAR包装.这是正确的还是我错过了什么?

The problem arises when declaring a dependency on these NARs from a non-NAR-packaged project. The maven-nar plugin never seems to get invoked. Only when I change the project's packaging to NAR does the maven-nar plugin kick in. This makes it seem like NAR packaging needs to be infectious in order to work, if there's a NAR dependency then all upstream projects need to be NAR-packaged. Is this correct or am I missing something?

使用maven-nar插件生成的本机共享库和JNI工件能否成功用于Web应用程序(即WAR)中?如果可以在WAR中使用和部署它们,该怎么做?否则,是否是将本机库手动放置在应用程序服务器上java.library.path中某个位置的唯一选择?

Can the native shared library and JNI artifacts produced using the maven-nar plugin be successfully used in web applications, i.e. WARs? If they can be used and deployed in a WAR, how is it done? Otherwise, is the only option to manually place the native libraries in some location in the java.library.path on the app server?

以下是该项目的POM的代码段,该代码段取决于NAR JNI工件:

Here's a snippet of the POM for the project that depends on the NAR JNI artifact:

  <?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>

不行,至少不容易.

如果您具有JNI,则需要弄乱-Djava.library.path甚至LD_LIBRARY_PATH/DYLD_LIBRARY_PATH/PATH,所有这些都必须在启动整个容器时进行.没有任何机制可以将所有这些从战争内部传播到容器中.

If you have JNI, you need to mess with -Djava.library.path and perhaps LD_LIBRARY_PATH/DYLD_LIBRARY_PATH/PATH, and all that has to happen in the launch of the overall container. There's no mechanism for propagating all that from inside a war to the container.

在成熟的Java EE中,JCA模型过去是/旨在成为将本机代码集成到Web应用程序中的方式.但是典型的轻量级容器不支持它.

In full-blown Java EE, the JCA model was / is intended to be the way that native code gets integrated in web applications. But typical lightweight containers don't support it.

如果您的本机代码不依赖于其他共享库,并且如果您不担心JVM本机代码冲突(给定的本机类只能位于一个类加载器中),那么您的问题仅仅是获取共享对象完全进入战争文件.

If your native code has no dependencies on other shared libs, and if you aren't concerned about JVM native code conflicts (a given native class can only be in one class loader), then your problem is merely getting the shared objects into the war file at all.

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

是一种方法.使用maven-dependency-plugin将共享库拖放到$ {project.build.directory}下的某个目录中,然后将其作为"Web资源"使用.

is one approach. Use the maven-dependency-plugin to drop the shared lib(s) into some directory under ${project.build.directory} and then pick them up as 'web resources'.