You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ja...@vianova.no on 2009/06/14 13:28:48 UTC
Handling JNI projects
Hello, I have a multiproject application that I want to port to maven.
I've managed to mavenize several of the projects that are pure Java with
apparently no error. So, my first impression is great. Now, I'm facing a
new challenge. One of the projects is using JNI and I have no idea about
if maven can handle this. I have seen several plugins supposed to do this
job, but I'm not sure after reading the one-page documentation about how
to proceed.
In a first phase, it is enough for me if I can make Maven to download the
compiled dll's, just because they are dll and no so. The libraries are
windows meant, so that is why I can go on using them as regular files.
In this matter, my question is how to make maven to download them. Is it
in the "package" goal?
Once this is fixed, in order to run tests I need to pass the
-Djava.library.path=/path/to/dll argument to the JVM. Is there any way to
have maven to compose this automatically? since they can be several, and
according to the maven repository layout they can be stored in different
folders. It would be nice if all the folder paths can be automatically
passed to the java.library.path argument.
If I achieve this then I'll feel very happy. But if can also port the
build of the native libraries to maven it would be perfect. Does anyone
have some tips for me? I would specially appreciate examples because I
have already read the yet-another-only-one-page documentation of the
native and the freehep plugins.
Please, keep in mind that my experience in Maven is only for 4 days.
Thank you all in advance.
Re: Handling JNI projects
Posted by Dan Tran <da...@gmail.com>.
Before I can jump to some sort of answer, first:
1. How do you build your jni and native libraries currently?
2. Is your native build multiplatform or windows only?
3. Do you have a need to download external native libraries and
corresponding include files for your build?
-D
On Sun, Jun 14, 2009 at 4:28 AM, <ja...@vianova.no> wrote:
> Hello, I have a multiproject application that I want to port to maven.
> I've managed to mavenize several of the projects that are pure Java with
> apparently no error. So, my first impression is great. Now, I'm facing a
> new challenge. One of the projects is using JNI and I have no idea about
> if maven can handle this. I have seen several plugins supposed to do this
> job, but I'm not sure after reading the one-page documentation about how
> to proceed.
>
> In a first phase, it is enough for me if I can make Maven to download the
> compiled dll's, just because they are dll and no so. The libraries are
> windows meant, so that is why I can go on using them as regular files.
>
> In this matter, my question is how to make maven to download them. Is it
> in the "package" goal?
>
> Once this is fixed, in order to run tests I need to pass the
> -Djava.library.path=/path/to/dll argument to the JVM. Is there any way to
> have maven to compose this automatically? since they can be several, and
> according to the maven repository layout they can be stored in different
> folders. It would be nice if all the folder paths can be automatically
> passed to the java.library.path argument.
>
>
> If I achieve this then I'll feel very happy. But if can also port the
> build of the native libraries to maven it would be perfect. Does anyone
> have some tips for me? I would specially appreciate examples because I
> have already read the yet-another-only-one-page documentation of the
> native and the freehep plugins.
>
> Please, keep in mind that my experience in Maven is only for 4 days.
> Thank you all in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Handling JNI projects
Posted by Martin Gainty <mg...@hotmail.com>.
you can configure surefire plugin to handle the setting of java.library.path
<dependencies>
<dependency>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties>
<property>
<name>java.library.path</name>
<value>target/lib/</value>
</property>
</systemProperties>
</configuration>
</plugin>
http://buildanddeploy.com/node/14
i have a PHP project which i would like to mavenize
PHP's apect which is most bothersome is that i am forced to compile native binaries to get PHP so/dlls to load to Apache
the reliability of maven is ensured by the adherence that every distro is a plugin which has groupId,artifactId and version
i can enforce C/C++ groupId thru namespace specification..artifactId thru filename and version as __VERSION macro
my Microsoft nmake tools are horribly out of date and consistently break ...not so for unix platforms
where a OS provider provides you with C,LINK and MAKE tools that are guaranteed to work with supplied OS
does maven have a makefile plugin available?
can we add a feature to ensure the supplied makefile produces maven mavenised (groupId,artifactId,version) plugins?
Takk!
Martin Gainty
______________________________________________
Note de déni et de confidentialité
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> To: users@maven.apache.org
> Subject: Handling JNI projects
> From: jaume.faus@vianova.no
> Date: Sun, 14 Jun 2009 13:28:48 +0200
>
> Hello, I have a multiproject application that I want to port to maven.
> I've managed to mavenize several of the projects that are pure Java with
> apparently no error. So, my first impression is great. Now, I'm facing a
> new challenge. One of the projects is using JNI and I have no idea about
> if maven can handle this. I have seen several plugins supposed to do this
> job, but I'm not sure after reading the one-page documentation about how
> to proceed.
>
> In a first phase, it is enough for me if I can make Maven to download the
> compiled dll's, just because they are dll and no so. The libraries are
> windows meant, so that is why I can go on using them as regular files.
>
> In this matter, my question is how to make maven to download them. Is it
> in the "package" goal?
>
> Once this is fixed, in order to run tests I need to pass the
> -Djava.library.path=/path/to/dll argument to the JVM. Is there any way to
> have maven to compose this automatically? since they can be several, and
> according to the maven repository layout they can be stored in different
> folders. It would be nice if all the folder paths can be automatically
> passed to the java.library.path argument.
>
>
> If I achieve this then I'll feel very happy. But if can also port the
> build of the native libraries to maven it would be perfect. Does anyone
> have some tips for me? I would specially appreciate examples because I
> have already read the yet-another-only-one-page documentation of the
> native and the freehep plugins.
>
> Please, keep in mind that my experience in Maven is only for 4 days.
> Thank you all in advance.
_________________________________________________________________
Insert movie times and more without leaving Hotmail®.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009
Re: Handling JNI projects
Posted by Benson Margulies <bi...@gmail.com>.
Not that I'm aware of. Keep in mind that this scheme requires running
unit tests and whatnot inside the OSGi universe. I don't know if
surefire can be persuaded to do that.
On Sun, Jun 14, 2009 at 11:47 AM, Martin Gainty<mg...@hotmail.com> wrote:
>
> so the solution would be to bundle/package the native libs in OS-classifier specific OSGI jars
> then identify the OS-classifier specific OSGI jar as a dependency plugin to pom.xml?
> does anyone have a working example ?
>
> thanks
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
>
>
>
>
>> Date: Sun, 14 Jun 2009 10:40:30 -0400
>> Subject: Re: Handling JNI projects
>> From: bimargulies@gmail.com
>> To: users@maven.apache.org
>>
>> There are some hard problems in handling JNI.
>>
>> First, while you can set java.library.path, you can't set PATH or
>> LD_LIBRARY_PATH or DYLD_LIBRARY_PATH, which you need on Windows,
>> Linux/Solaris, or MacOS respectively.
>>
>> If you really plan to retrieve the shared objects as maven artifacts,
>> then they will arrive in your local repo, and you have to set these
>> environment variables to the directories where they land.
>>
>> If you want to support multiple platforms, you have to worry about
>> that. Classifiers might be helpful for this.
>>
>> It has seemed to me that perhaps a creative mashup of OSGi and maven
>> might produce something handy here, since OSGi bundles/fragments can
>> carry native libs, and the OSGi runtime undertakes to get all the
>> environment variables and such set up for you.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> _________________________________________________________________
> Hotmail® has ever-growing storage! Don’t worry about storage limits.
> http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Handling JNI projects
Posted by Martin Gainty <mg...@hotmail.com>.
so the solution would be to bundle/package the native libs in OS-classifier specific OSGI jars
then identify the OS-classifier specific OSGI jar as a dependency plugin to pom.xml?
does anyone have a working example ?
thanks
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Sun, 14 Jun 2009 10:40:30 -0400
> Subject: Re: Handling JNI projects
> From: bimargulies@gmail.com
> To: users@maven.apache.org
>
> There are some hard problems in handling JNI.
>
> First, while you can set java.library.path, you can't set PATH or
> LD_LIBRARY_PATH or DYLD_LIBRARY_PATH, which you need on Windows,
> Linux/Solaris, or MacOS respectively.
>
> If you really plan to retrieve the shared objects as maven artifacts,
> then they will arrive in your local repo, and you have to set these
> environment variables to the directories where they land.
>
> If you want to support multiple platforms, you have to worry about
> that. Classifiers might be helpful for this.
>
> It has seemed to me that perhaps a creative mashup of OSGi and maven
> might produce something handy here, since OSGi bundles/fragments can
> carry native libs, and the OSGi runtime undertakes to get all the
> environment variables and such set up for you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009
Re: Handling JNI projects
Posted by Benson Margulies <bi...@gmail.com>.
There are some hard problems in handling JNI.
First, while you can set java.library.path, you can't set PATH or
LD_LIBRARY_PATH or DYLD_LIBRARY_PATH, which you need on Windows,
Linux/Solaris, or MacOS respectively.
If you really plan to retrieve the shared objects as maven artifacts,
then they will arrive in your local repo, and you have to set these
environment variables to the directories where they land.
If you want to support multiple platforms, you have to worry about
that. Classifiers might be helpful for this.
It has seemed to me that perhaps a creative mashup of OSGi and maven
might produce something handy here, since OSGi bundles/fragments can
carry native libs, and the OSGi runtime undertakes to get all the
environment variables and such set up for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org