Ticket #667 (closed task: fixed)

(was "Changed 13 months ago by aivar", moved from ImageJ Trac)

Investigated the Maven Nar plugin. This provides a way of building on multiple platforms and consolidating the resultant native libraries in a central Maven repository. It also provides native libraries for the current platform during development. However it is lacking in support for running platform-appropriate native libraries during application runtime.

Maven Nar install "installs produced artifacts in the local repository. The unpacking is done in the unpack goal of a dependent artifact upon first usage". In AbstractUnpackMojo it is again stated "unpacking happens in the local repository". The generated NarSystem doesn't actually do any unpacking, it merely appends a version specific string, such as "-2.0-SNAPSHOT", to the library name.

I created a Native Library Utility project to unpack Nar-generated native libraries from a Jar file. It uses open source code from Richard van der Hoff:

 http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI

 http://opensource.mxtelecom.com/maven/repo/com/wapmx/native/mx-native-loader/1.7/

It also uses a trick to add a directory to the java.library.path properties.

 http://nicklothian.com/blog/2008/11/19/modify-javalibrarypath-at-runtime/

(was "Changed 12 months ago by aivar", moved from ImageJ Trac)

At the February 2011 Fiji Hackathon Johannes Schindelin told me about cross-compilation with gcc. This is a much better solution than having to build a Maven Nar for each platform we support, on a machine running that platform, and consolidate these in the repository.

I am currently using the Maven Native plugin and working on cross compilation within Maven, based on the information at  http://www.tricoder.net/blog/?p=197 .

(was "Changed 11 months ago by aivar", moved from ImageJ Trac)

Have a cross-compilation scheme that compiles for Windows and Linux on Linux (i.e. our Hudson/Jenkins build machine) and OSX on OSX, but haven't applied it to the SLIM Plugin.

Worked on being able to create Instrument Response Function, aka Prompt, aka Excitation within plugin, save/restore, display, initialize and edit cursors.

(was "Changed 11 months ago by aivar", moved from ImageJ Trac.)

Added Instrument Response Function functionality, although I'm not sure it's working quite right. Added an automatic fit with RLD followed by LMA capabiilty, had some difficulty with that breaking the ability to fix fit parameters. Discovered export to text was completely not working and dealing with multiple channels was broken also and fixed those.

I was diverted by all these major issues and haven't gotten the multiplatform release working yet.

(Was "Changed 2 months ago by aivar", moved from ImageJ Trac.)

I have something that works but the build process is really ugly. I'll leave this open for improvements.

I also created a ticket #668 to specifically address just putting together an up-to-date version using these techniques.

Now that SLIM Plugin is being distributed as a Fiji plugin, we could adopt the Fiji plugin scheme of handling native libraries. Whereas the ideal ImageJ distribution was to build one big jar with everything in it, Fiji handles distributing and updating each component jar or native library. With Fiji the native libraries are placed in a 'lib' directory that is on the classpath, under a platform specific path. The Fiji updater handles them like any other component of the plugin.

I need to provide document for the multi-platform build process.

Created an initial release of curve-fitter-1.0-SNAPSHOT-with-libs.jar, a hand-created jar with the native libraries in it. I did document my multi-platform build process but it is really ugly.

Meanwhile it looks like Johannes has figured out how to use the Maven NAR plugin to build multi-platform FIJI launchers. I'm leaving this ticket open to cover adopting that scheme.

Adopted Johannes's scheme to build cross-platform SLIM Curve libraries.