[
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602439#comment-14602439
]
Kristian Rosenvold commented on MNG-5847:
-----------------------------------------
Unless you want to fix the isse yourself, you're relying that some commiter has
sufficient understanding of your problem to fix it. So while I might be able to
fix the problem, I am not very familiar with native stuff. So by making a test
project you'd increase the chance of getting this issue fixed. Is there any
chance you could use some existing stuff with native code from maven central ?
(org.xerial.snappy/snappy-java comes to mind) ? Otherwise I'm afraid you'll
have to fix the issue yourself and create a patch
> Maven controls java.library.path
> --------------------------------
>
> Key: MNG-5847
> URL: https://issues.apache.org/jira/browse/MNG-5847
> Project: Maven
> Issue Type: Wish
> Reporter: Markus Karg
> Labels: dill, jni, lib, native, so
>
> We have many Java projects that are dependent of other Java projects which
> make use of JNI. Hence, when we do "mvn test" in our project, we fail
> frequently as the native part of the dependency is missing, even if we
> declare the native part as an explicit dependency. There are several ideas
> how to solve that, but non of them is complete or sufficient.
> The solution users expect would look like this:
> * MyProject has one dependency to OtherProject of <type>*</type> (asterisk
> means: Maven selects best fit).
> * OtherProject offers many different packages, e. g. win-x86-dll,
> win-x64-dll, linux-so-64, etc.
> * When doing mvn test on MyProject, Maven checks ALL exiting packages for the
> dependency's coordinates, and select that package that is the best fit for
> the current execution enviroment. For example, it select "win-x86-dll" when
> run on Windows (32 Bit), or selects "linux-so-64" when run on Linux (64 Bit)
> etc. This mechanism should be extensible by future extension plugin, so a
> third party vendor can simply provide addtional mappings via Maven Central.
> * Just as Maven does a configuration of the ClassPath from all JAR
> dependencies, it now will now do a configuration of all native dependencies.
> That means, it copies the selected native dependencies to target/dependencies
> and builds a synthetic java.library.path system property.
> * As a result, adding a native dependency will work on any platform without
> any complex pom.xml tweaks.
> * The solution shall not be a Java-only solution, but it shall work with any
> kind of toolset. So a toolset plugin shall be able to utilize the core
> mechanism and adapt it to its own needs, which includes for example the fact
> that setting java.library.path is job of the Java Toolset Plugin, while
> providing a similar lookup mechanism is job a hypothetical different Toolset
> Plugin.
> We would really beg the Maven team to provide such a solution, as JNI is an
> integral part of Java for really long time, and we have this problem every
> other day.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
