[
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741674#comment-16741674
]
Sylwester Lachiewicz commented on MNG-5847:
-------------------------------------------
This issue has been auto closed because it has been inactive for a long period
of time. If you think this issue still applies, retest your problem with the
most recent version of Maven and the affected component, reopen and post your
complete example with results.
> 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
> Priority: Major
> 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
(v7.6.3#76005)
