Clean up native platform naming across ImageJ2 components

[ctrueden]

There are at least four different places where platform naming comes into play:

1. Bare native libraries for ImageJ/ImageJ2/Fiji. The ImageJ Launcher detects the platform, and sets java.library.path to include a folder lib/<platform>, which currently supports five values: lib/win32, lib/win64, lib/macosx, lib/linux, and lib/linux-amd64. Here is the logic where that is defined.

2. Native libraries wrapped in JAR files. The ImageJ Updater names the platforms slightly differently: jars/win32, jars/win64, jars/macosx, jars/linux32, and jars/linux64 (there is also tiger, for long-obsolete old versions of Mac OS X). Definitions are here, used in various places around the Updater code. The Updater selects the appropriate platform, marking files automatically as suitable only for the matching platform, for things in the correct lib or jars subdirectory.

3. Naming of native classifier JARs. For example, jogl-all-2.3.2-natives-linux-i586.jar. Highly inconsistent across projects in the wild. See here and here and here for more discussion. One detail of note is that pom-scijava-base defines a property scijava.platform.arch which is generally equal to Java's os.arch except that for x86-compatible architectures (e.g. x86_64, amd64) it simplifies it down to simply the number (e.g. 64). But for non-x86 e.g. Mac M1's ARM 64-bit architecture it will be the full os.arch value e.g. arm64.

4. Subdirectory naming convention for native-lib-loader. The native-lib-loader project enables dynamic loading of native libraries from inside JAR files, so that the JARs describe above in (3) can have their wrapped natives loaded easily. We use it in projects like FLIMLib to easily utilize native code from Java. Unfortunately, it has its own incompatible naming convention as well, distinct from (1), (2), and (3) above.

I dislike the inconsistency in naming across these four areas, and would prefer to reconcile and standardize the naming where possible, particularly now that Mac M1 machines are in the wild using ARM architecture.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/migrating-from-fiji-clij-to-napari-pyclesperanto/54985/73

[ctrueden]

With scijava/pom-scijava-base@804fa6734871b402e55cce04833cd71c63d1b3cb, pom-scijava-base now defines naming conventions for javacpp- and jogl-based native classifier artifacts. With scijava/pom-scijava-base@81f583d6ac8e1b6b3eed5cd3a4c66146381be5ed, this naming is extended to support arm64/aarch64 (e.g. Mac M1).

It doesn't solve the naming discrepancies described above, but it does make dealing with item (3) in a platform-agnostic way easier from inside Maven POMs that extend pom-scijava.