Major Description
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.