Even if this plugin may be useful, you may have a look at the official dependency plugin which is much more maintained and becomes more flexible over time (eg https://issues.apache.org/jira/browse/MDEP-628 & https://blogs.apache.org/maven/entry/apache-maven-dependency-plugin-version2)
This Maven plugin will unpack the native dependencies (usually .so files on Linux, DLLs on Windows) into a single folder.
Those "native" dependencies are recognized thanks to the Maven classifier which must start with the "natives-" prefix.
If those artifacts are .zip, .tgz, (.7z are not fully supported) or any other recognized format, their content will be transparently extracted (optionally in different subdirectories) in target/natives/ directory.
By default, in case of a multi module project, we will unpack all natives dependencies to the same dir (thus saving space and unzip time while allowing all interdependent projects to benefit from the presence of native libs)
Those libraries may be handled by this plugin:
TODO: add configuration exemple for each one
The plugin is available from Maven Central, just add the following snippet to your pom to use it:
<project>
...
<build>
<plugins>
<plugin>
<dependency>
<groupId>com.teamtter.mavennatives</groupId>
<artifactId>nativedependencies-maven-plugin</artifactId>
<version>1.0.6</version>
<executions>
<execution>
...
</executions>
<configuration>
...
</configuration>
<plugin>
...<plugin>
<groupId>com.teamtter.mavennatives</groupId>
<artifactId>nativedependencies-maven-plugin</artifactId>
<version>1.0.5</version>
<executions>
<execution>
<id>unpacknatives</id>
<phase>generate-resources</phase>
<goals>
<goal>copy</goal>
</goals>
</execution>
</executions>
<configuration>
<skip>false</skip>
<!-- autoDetectDirUpInFilesystem is documented below-->
<autoDetectDirUpInFilesystem>true</autoDetectDirUpInFilesystem>
<!-- if autoDetectOSNatives is 'true' then you don't need the 'osFilters' list -->
<!-- we advise you set 'autoDetectOSNatives' to true and forget about osFilters -->
<autoDetectOSNatives>false</autoDetectOSNatives>
<byTypeFilter>so,dll</byTypeFilter> <!-- we want to copy files whose type is dll an so -->
<!-- <nativesTargetDir>${session.executionRootDirectory}/target/natives</nativesTargetDir> -->
<!-- <separateDirs>true</separateDirs> -->
<osFilters>
<osFilter>
<osName>linux</osName>
<osArch>64</osArch>
<suffix>linux</suffix>
</osFilter>
<osFilter>
<osName>windows</osName>
<!-- <osArch>64</osArch> --> <!-- this line is not mandatory -->
<suffix>win</suffix>
</osFilter>
</osFilters>
</configuration>
</plugin>By default, as you can see commented above (parameter nativesTargetDir), the default directory will be "${session.executionRootDirectory}/target/natives".
This means that in a multi-module configuration, you can have all you native dependencies extracted alongside the main pom in ./target/natives.
This allows you to have a single location where are stored all your native libs, as long as you always run maven related commands FROM THE ROOT DIRECTORY.
If you want to target a specific child module, you can use the --projects parameter: mvn install --projects my-child-module
But in the real world you sometimes run child-modules directly from their own directory. Then you would loose time unzipping the native dependencies each time in a different child. So we introduced the autoDetectDirUpInFilesystem parameter. It will (try to) autodetect the root of your maven tree and always unzip in the target/native directory alongside your parent pom. Even when you run Maven from a child module.
|
Warning
|
implementation is quite naive and handles only tree file structure like this: |
parent-module
|
|- pom.xml
|- child module 1
| |
| |- pom.xml
|
|--child parent module
|- pom.xml
|
|- lowest child module
|
|- pom.xml|
Warning
|
there was once an Eclipse extension but not actively used nor developped. It has been removed on 2021/07/16 |
In the future we could restore it, the goal would be to automatically unzip dependencies directly from the IDE and add the folder to the PATH when running Eclipse launchers.
Point Eclipse to the following update site:
The Maven Users mailing list may also be a good start.
Or you can always open an issue directly on Github.
This is a fork of the previously existing Maven Native Dependencies project which was at version 0.0.7.
The maven plugin has then been renamed to "nativedependencies-maven-plugin" to follow Apache Maven conventions and groupId changed to "com.teamtter.mavennatives".
Big thanks to the original writers of Maven Native Dependencies.
Reasons for forking original project:
-
add finer grain control over what natives dependencies will be unpacked.
-
familiarize myself with the dev of Maven plugins.
-
improve eclipse plugin (NOT done at the moment)
-
finally find a way to prevent each and every project using native libs to have to manually (god I hate this word!) configure the -Djava.library.path and LD_LIBRARY_PATH
Current features added to original plugin:
-
generate a variable containing location of the directory where natives are unpacked ( use ${nativesTargetDir} in you pom ).
-
use GitHub instead of the dead Google Code
-
more modern code using annotations
-
parameter to be able to skip the plugin execution (overridable through a variable)
-
add parameters to auto-detect platform and get only platform specific libs
-
transparently handle misc compression format (zip, tar, tgz, 7zip…) and single file not compressed deps (.dll, .so, .dylib…)
-
keep a cache of the signature for each compressed artifact to avoid uncompressing it again if it has not changed. #performance
Commited code is compiled by Travis-CI
Eclipse’s Tycho seem to require Java 8.
Apache License 2.0