[ https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylwester Lachiewicz closed MNG-5847. ------------------------------------- Resolution: Auto Closed > 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)