Hi all, > http://dev.loci.wisc.edu/trac/software/browser/branches/maven/projects/native-library-util/src/main/java/com/wapmx/nativeutils/jniloader/NativeLoader.java?rev=7574
Some notes about this code: 1) The above URL is to an SVN repository that has since been migrated to Git. The current URL for the project is: https://github.com/scijava/native-lib-loader 2) The SciJava native-lib-loader project is a fork [1] of Richard van der Hoff's mx-native-loader project, which is also available from its own Maven repository [2], and has several other forks floating around on GitHub, too. Since we forked (at version 1.7), the author has released a newer version (1.8), which we have not reconciled with the SciJava code. Regards, Curtis [1] https://groups.google.com/d/topic/scijava/D4SVBhGhb1g/discussion [2] http://opensource.mxtelecom.com/maven/repo/com/wapmx/native/mx-native-loader/ On Fri, Jan 4, 2013 at 2:45 PM, Stuart Maclean <stu...@apl.washington.edu>wrote: > Sorry Martin, I missed some of your points: > > > Hi from a newbie.MG>a newbie with extensive experience with maven and >>> make files! >>> >>> > Ah yes, I meant new to mailing list ;) > > > 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/**branches/maven/projects/** > native-library-util/src/main/**java/com/wapmx/nativeutils/** > jniloader/NativeLoader.java?**rev=7574<http://dev.loci.wisc.edu/trac/software/browser/branches/maven/projects/native-library-util/src/main/java/com/wapmx/nativeutils/jniloader/NativeLoader.java?rev=7574> > > Essentially yes, that is it. I did try contacting the original author, to > no avail. I can't recall now if I was able to get that artifact from a > repo or had to install it manually. > > > of a poor man's AOL (from the nar plugin, which I ended up NOT using). > MG>did'nt catch the reasons why you do'nt want to use nar..explain please > > I didn't use NAR as I was worried it was unsupported,fragmented and overly > optimistic on what it was trying to achieve. I could live with the exec > plugin firing make, I am happy in make myself.tion across many > > platform Makefiles. MG>smart ..OS and compiler specific variables should >>> be aggregated in OS and compiler specific profiles >>> >>> > Yes. I cannot fathom why there is no easier way to run javah from Maven. > It certainly isn't 'native' the way gcc is 'native'. It's a standard Java > tool running on .class files. OK, it produces C headers but that doesn't > make it 'native'. I may switch to the antrun-plugin for the javah step, > since the native-maven-plugin looks a bit alpha itself, and I don't use it > for any 'heavy lifting', I use make. > > MG>app code? >> MG>JNI ?MG>How is the app PATHed to native binaries? >> > > See last post, you don't need any LD_LIBRARY_PATH nor -Djava.library.path. > > I should qualify this by saying that in PRINCIPLE this should all work on > Windows, I have NOT actually tested it, I have just tested Linux 32 and 64 > bit. > > > > Stuart > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org > >
