[ https://jira.codehaus.org/browse/MNG-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341516#comment-341516 ]
Markus KARG commented on MNG-5448: ---------------------------------- What I proposed is that Maven learns to deal with binary dependencies in a very sophisticated and simple-to-use way. NAR does not do that. It puts up a heavy load on the user and the runtime system. Until today, nobody was able to provide a simple and easy to apply config example how NAR could solve the issue I expressed in the above feature request. Hence I really beg that Maven will provide a <type>dll</type> DEPENDENCY support (this is about DEPENDENCIES, not about PRODUCING binary packages)! :-) If someone knows a dead-simple solution _with_ NAR, then please post the config NOW AND HERE so we can all be happy without a change in Maven. ;-) Regards -Markus > Putting dll/so-type dependencies on java.library.path by default > ---------------------------------------------------------------- > > Key: MNG-5448 > URL: https://jira.codehaus.org/browse/MNG-5448 > Project: Maven 2 & 3 > Issue Type: Story > Reporter: Markus KARG > > Many people are using Maven to build products that are using native > dependencies (e. g. using JNI directly or indirectly). These people have to > declare in some way this dependency, so Maven will download the DLL/SO to > [target]. But what they also need is to tell Java that the target folder has > to be scanned for the DLL/SO, hence they need to set java.library path. > There are several solutions but all of them lack one thing: They are no > default but always do "tricks". This is a problem, because: > * m2e needs to tell Eclipse where to find DLLs. > * There might be other tools that want to read or write the POM. > * How should different tools understand that DLL dependencies are to be put > on java.library.path if there is no STANDARD way to find this information in > the POM? > The only "real" solution would be that Maven 3.1 clearly defines the one and > only unique way! > In my opinion the way clearly means: > * Clearly define that any <packaging>dll</packaging> and > <packaging>exe</packaging> dependencies MUST be put to [target/native] and > that [target/native] MUST be part of java.library.path! > That way, it will become most simple to use any DLL/SO as a dependency, > either Maven-built or not. And it will be absolutely clear to m2e and any > other tools that such dependencies must be told to Eclipse and other > environments as to be put on the java.library.path! > I do not say that it must exactly work THIS way, but what I really like to > say is that Maven MUST provide ONE and EXACTLY ONE clear and unambiguous way > to tell ANY POM-reading tool that a dependency is a DLL/SO and MUST be found > on java.library.path in turn. > This is NOT up to the POM author, as it is pretty clear that ANY DLL/SO that > is a dependency only serves the single and simple purpose of BEING on > java.library.path -- otherwise one would not have made it a dependency! > I mean, ANY JAR dependency is put on the CLASSPATH already, so it makes > pretty much sense to do the same with DLL/SO dependency and java.library.path! -- This message was sent by Atlassian JIRA (v6.1.6#6162)