maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MNG-5847) Maven controls java.library.path
Date Wed, 01 Jul 2015 20:36:06 GMT

    [ https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610964#comment-14610964
] 

Robert Scholte commented on MNG-5847:
-------------------------------------

On the mainpage we say "Apache Maven is a software project management and comprehension tool.
Based on the concept of a project object model (POM), Maven can manage a project's build,
reporting and documentation from a central piece of information."
It doesn't even mention Java as the technology, although everybody knows that it all started
with Java (which explains a lot of default values). I've written several plugins to build
non-java projects, just because Maven was the best fit for it.

> 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)

Mime
View raw message