Hi all,
Apologies in advance for the length of this mail. As you'll see, I've
been thinking about this for a while, but I want to get it right first
time rather than end up supporting legacy builds in the future. I'm
looking for suggestions on how best to handle native libraries. We have
quite a few projects here which have JNI code, so I'm after a neat,
reusable solution.
I'm keen to avoid the structure proposed at
http://svn.codehaus.org/trunk/mojo/maven-native/native-maven-plugin/src/it/jni/?root=mojo
which has quite a nested format, which seems to me to (a) cause
unnecessary clutter and (b) limit sharing between projects. Better would
be just one 'native' subproject (alongside a 'java' subproject). I'm not
going to rule out the whole native/{Linux,win32,etc} system - it just
isn't clear to me at the moment that it helps much.
Anyway, I face a whole array of problems :/
The first is how an application finds its native libraries.
System.loadLibrary() loads its libraries from the System property
"java.library.path". The easiest way of achieving this seems to be to
use an assembly to build an archive containing the libraries, so that
they can just be loaded from the correct directory. Bit of a pain to
have to build and extract an assembly on each build cycle, but there you go.
However, there is also a problem with what the library file is named.
Having the version number in the filename would mean that the java side
needs to know about the version of the native library (rather than just
transparently loading whatever happens to be there), so I'd rather avoid
that. Furthermore, different platforms have different requirements for
the naming of their jni libs - for instance, for a library "foo", Linux
requires libfoo.so, win32 requires foo.dll, etc - all of which is
somewhat incompatible with the naming conventions of maven artifacts.
This brings me to my next thought, which is that the maven "artifact"
probably ought to be a zip file (or similar) containing the
correctly-named library. This is good because it means my artifacts have
the same extension no matter what platform they were built for; I can
distinguish between platforms using the classifier; and I can be sure
that the name of the library itself is just right for the given platform.
On the other hand, it means I now need to set up my assembly such that
the zip files are unpacked. Ideally, I'd like for all such artifacts to
be unpacked automatically, but there doesn't seem to be any way of doing
so without configuring it in each assembly.xml. It's a property of the
artifact, rather than the assembly, so it would be nice to somehow
derive this from an ArtifactHandler rather than in the assembly
descriptor. I can probably fudge this with a shared assembly descriptor,
however.
As an alternative approach, I considered storing the artifact in the
repository with the right prefix and suffix, and maybe letting the java
side know the right version with some sort of properties magic - which
might make the building of assemblies simpler, and would even allow you
to do without an assembly if you set up your java.library.path to
include bits of the local repository. However, that would seem to
require that the DefaultRepositoryLayout allows the ArtifactHandler to
specify a prefix as well as an extension, so that's a bit of a
fundamental change.
I'm assuming either solution is going to involve me creating my own mojo
to actually create the relevant artifact in the first place - but I'm
going to think harder about that once I've decided what I want the
repository to contain!
So, any thoughts, comments, criticism or praise on my line of thinking
above would be very much appreciated.
Cheers
Rich
--
Richard van der Hoff <[EMAIL PROTECTED]>
Systems Analyst
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
