Hi Stuart, > I didn't use NAR as I was worried it was unsupported,fragmented and > overly optimistic on what it was trying to achieve.
FYI, there is now an attempt at unification of the maven-nar-plugin at: https://github.com/maven-nar/maven-nar-plugin As well as a maven-nar-plugin mailing list: https://groups.google.com/forum/?fromgroups#!forum/maven-nar But since all the involved folks have other full-time projects, you are probably right about the project goals being overly optimistic. :-) More help on the project is very welcome. Regards, Curtis On Fri, Jan 4, 2013 at 2:45 PM, Stuart Maclean <[email protected]>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<[email protected]> > For additional commands, e-mail: [email protected] > >
