Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of mgainty@hotmail.com designates
 65.55.116.14 as permitted sender)
Message-ID: <BLU172-W264DF4D67D61B8ADA7D99CAE200@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_a23e2673-c8ae-44b4-ad8e-aa43ea2994a1_"
From: Martin Gainty <mgainty@hotmail.com>
To: "users@maven.apache.org" <users@maven.apache.org>
Subject: RE: JNI jars dependencies
Date: Fri, 4 Jan 2013 15:23:20 -0500
Importance: Normal
In-Reply-To: <50E73386.1060500@apl.washington.edu>
References: 
 <CANyrOm5mzocyaBDtNpGY+hPuYGniXZfwKD9k77xVDNfd9GJ27g@mail.gmail.com>,<50E73386.1060500@apl.washington.edu>
MIME-Version: 1.0

--_a23e2673-c8ae-44b4-ad8e-aa43ea2994a1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  > Date: Fri=2C 4 Jan 2013 11:54:46 -0800
> From: stuart@apl.washington.edu
> To: users@maven.apache.org
> Subject: Re: JNI jars dependencies
>=20
> Hi from a newbie.MG>a newbie with extensive experience with maven and mak=
e files!
>=20
> I too have been fighting with how best to develop maven artifacts=20
> containing jni parts.  Though I found several useful posts on jni and=20
> maven =2C e.g.
>=20
> http://www.tricoder.net/blog/?p=3D197
>=20
> http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI
>=20
> http://www.humboldt.co.uk/2009/02/wrapping-a-native-library-with-maven.ht=
ml
>=20
> in the end I rolled my own solution=2C something I wanted to avoid.  My=20
> goal was to produce usable artifacts that worked across platforms=2C ie=20
> linux 32 and 64 bit and perhaps windows.  Here's some notes on my=20
> experiences over the past 3-4 days.  My particular jni effort was to=20
> 'Java-ify' an existing C library.
>=20
> I isolated the Java classes which had native methods into a single Maven=
=20
> module=2C so producing a single artifact.  I placed the Java sources unde=
r=20
> the regular src/main/java.  In the pom=2C I used maven-native-plugin to=20
> invoke javah to produce the headers (jn the default location=20
> target/native/javah).  In the same pom=2C I then used the exec plugin to=
=20
> invoke make in ./native/${os.name}.  Both of these are bound to the=20
> compile phase=2C so a simple
>=20
> mvn
>=20
> will compile Java=2C run javah=2C then locate correct Makefile and run it=
.
>=20
>    I then added makefiles to ./native/Linux and ./native/Windows.  In=20
> the Linux makefile=2C I used VPATH to locate the C sources in=20
> ${basedir}/src/main/c.  The final .so file (which has no platform/arch=20
> encoded into its name=2C ie is just libfoo.so) is copied by the make into=
=20
> ${basedir}/target/classes/META-INF/lib=2C so the package phase will locat=
e=20
> the .so at /META-INF/lib/libfoo.so=2C from which the nifty=20
> com.wapmx.native loader can unpack it at runtime. MG>is this NativeLoader=
 what you're alluding toMG>http://dev.loci.wisc.edu/trac/software/browser/b=
ranches/maven/projects/native-library-util/src/main/java/com/wapmx/nativeut=
ils/jniloader/NativeLoader.java?rev=3D7574
>=20
> The whole artifact is then named
>=20
> NAME-${os.arch}-${os.name}  and installed and/or deployed.  this is sort=
=20
> of a poor man's AOL (from the nar plugin=2C which I ended up NOT using). =
MG>did'nt catch the reasons why you do'nt want to use nar..explain please
>=20
> Then a project/module which depends on this artifact simply uses the=20
> name above.  It's a bit crude=2C but for 2 or 3 platforms maximum=2C I th=
ink=20
> it will be manageable.
>=20
> Points:
>=20
> the javah invocation could have been done either from Maven or make.  I=20
> chose to to it in Maven=2C mostly to avoid duplication across many=20
> platform Makefiles. MG>smart ..OS and compiler specific variables should =
be aggregated in OS and compiler specific profiles
>=20
> I use the wapmx artifact to extract the native lib from the jar=2C better=
=20
> than requiring LD_LIBRARY_PATH solutions.
>=20
> My particular jni scenario required that the Java side maintain C=20
> pointers (in both directions).  Knowing that these would be 64 bits wide=
=20
> on 64 bit platforms=2C I had to use Java longs and jlong in the C code. =
=20
> Compiling on 32 bit Linux=2C I then had to add
>=20
> ifeq ($(shell uname -m)=2Ci686)
> # want any warning to raise error=2C but silence any 64/32 bit conversion=
s
> CFLAGS +=3D -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast
> endif
>=20
> to the Makefile to silence the compiler's warnings.  I always compile=20
> with -Werror (any warning is an error=2C fail to build)
>=20
> In the C link phase in my makefiles=2C I statically linked the C library =
I=20
> am wrapping=2C call it W.  To do this=2C I used an explicit file name=2C =
eg.
>=20
> cc -o libfoo.so /path/to/libW.a my1.o my2.o
>=20
> I tried fancy -Wl=2C-static and -Wl=2C-shared linker options but it alway=
s=20
> failed to link.  I should point out that I had sources to libW=2C so coul=
d=20
> configure/make it as desired.
>=20
>=20
> Then my end user (who is handed just a single jar) does not need any=20
> libW.so at runtime.MG>whats inside the uber.jar?
MG>app code?
MG>JNI ?MG>How is the app PATHed to native binaries?
>=20
>=20
> Paths I investigated but did not finally use:
>=20
> having the Java classes containing the native methods (call it A) and=20
> the actual .so (call it B) as separate Maven modules=2C as explained in=20
> the first url above. Then B depends upon A being built so that javah can=
=20
> locate .class files=2C but then how do you run test cases in A=2C since y=
ou=20
> need native code in B.MG>perhaps aggregate the plugins for B into a child=
 module?
>=20
> I did not use maven-nar-plugin=2C since as suggested=2C it is really a Ma=
ven=20
> solution to wider native development.  I had a localised (or so I think)=
=20
> jni issue.
>=20
> I used maven-native-plugin over the antrun-plugin=2C which apparently=20
> would also give access to javah (would this require an extra Ant=20
> build.xml or can this be 'embedded' in the pom???) MG>forked ant targets =
cause classloader issues=2C resource-limitation issues and passing maven-pr=
operties to ant build.xml and return MG>back...unless there is a political =
reason to do so..stay with maven
>=20
> Comments=2C suggestions welcomed
>=20
> Stuart
>=20
> ---------------------------------------------------------------------
> To unsubscribe=2C e-mail: users-unsubscribe@maven.apache.org
> For additional commands=2C e-mail: users-help@maven.apache.org
>=20
 		 	   		  =

--_a23e2673-c8ae-44b4-ad8e-aa43ea2994a1_--