Add GitHub Actions CI (Linux, macOS, Windows × Java 8, 21)

[mkitti]

Stacked on #9. Adds CI; until now the repository had none, so nothing in #1–#9 had been tested outside one macOS arm64 machine.

Workflow

.github/workflows/build.yml runs mvn -B -U test on every pull request (any base branch), on pushes to main, and on demand:

	Java 8	Java 21
ubuntu-latest	✓	✓
macos-latest (arm64)	✓	✓
windows-latest	✓	✓

• fail-fast: false, so one platform failing doesn't hide the others.
• Zulu JDKs, because Temurin has no Java 8 for macOS arm64.
• On failure, the surefire reports and any hs_err_pid*.log crash dumps are uploaded as artifacts.

pom.xml changes needed for CI

• Snapshot repository: oss.sonatype.org snapshots is shut down. The org.bytedeco snapshots (including hdf5:2.2.0-1.5.15-SNAPSHOT) now live at https://central.sonatype.com/repository/maven-snapshots/. I also dropped the unused snapshot plugin repository.
• Natives for the build platform: the org.bytedeco:hdf5 natives dependency is fixed to macosx-arm64. New OS/arch-activated profiles add the build platform's natives jar in test scope (linux-x86_64, linux-arm64, macosx-x86_64, windows-x86_64). What consumers of the artifact get is unchanged.
• ciManagement now points at GitHub Actions.

Checked locally with an empty -Dmaven.repo.local, so everything came from the remote repositories as on a CI runner: 348/348 tests pass against the published snapshot.

First results

• Linux and macOS, Java 8 and 21: all 348 tests pass. This is the first time the suite has run on Linux.
• Windows: 306/348 fail, for one reason outside this repository. The Windows jobs are marked continue-on-error so they stay visible without failing the workflow.

Why Windows fails. On Windows, the org.bytedeco:hdf5 preset links HDF5 statically into jnihdf5.dll: link = {"zlibstatic", "libhdf5", ...}, and with HDF5's CMake build libhdf5.lib is the static library, while hdf5.lib is the DLL's import library. hdf.hdf5lib's hdf5_java.dll uses hdf5.dll. So every Windows process has two independent HDF5 libraries. The property list created by H5.H5Pcreate is unknown to the bytedeco copy, so the first H5Pset_type_conv_cb fails (with an empty error stack, because we read the other copy's stack). On macOS and Linux both bindings share one libhdf5, which is why only Windows fails.

Fix this in javacpp-presets by linking the import libraries (hdf5, hdf5_cpp, hdf5_hl, hdf5_hl_cpp) on Windows, then drop continue-on-error. A few Windows-only test failures (uid/gid names, the jMock-based DirectoryIndexUpdaterTest) may remain after that.

Not addressed here

• Consumer natives: the published artifact still pulls in only macosx-arm64 natives, so downstream users on other platforms get no native HDF5. Probably worth fixing separately, for example with hdf5-platform or by leaving the natives choice to consumers.

🤖 Generated with Claude Code