Deploying a new JHDF5 jar to maven

[mkitti]

@ctrueden said in bigdataviewer/bigdataviewer-core#135 (comment)

We could either:

1. Deploy a new fat jhdf5-19.04.0.1 all architectures in one; or
2. Split up the architectures to make one classifier per arch, and then add the aarch64 one to that; or
3. Just deploy the aarch64 arch as a separate add-on JAR to the main jhdf5-19.04.0.

I don't have a strong opinion. I think (2) is most correct, but would be more work, whereas (3) would be simplest but require anyone with an M1 mac to explicitly depend on the aarch64 architecture JAR. (1) would keep things simple for users but result in an increasingly bloated JHDF5 JAR file.

At the same time, I think we should consider how to address the shared library issue #2 so that we can take advantage of HDF5 compression plugins.

[skalarproduktraum]

Hi @mkitti! I've just tried your latest fat JAR which @tpietzsch had pointed out on Gitter. Works great so far, thanks for adding M1 support!

With regard to the deployment -- in scenery, before the lwjgl included a shader compiler, we had build that on our own and deployed the natives separately (in https://github.com/scenerygraphics/spirvcrossj). Building them separately and deploying worked well and also had the additional benefit that it was clear which archs worked. That being said, if any help is needed, let me know 👍

cheers!

[mkitti]

Thanks. There are several levels of complexity here. The major one is that this is a fork of the original ETH code base.

The second is waiting for the SciJava ecosystem to update to JHDF5 19.04.

I'll definitely take a look at how you ended up deploying native libraries though!

[mkitti]

Adding a note for myself that the current pom is here:
https://github.com/scijava/pom-scijava/blob/master/non-maven/jhdf5-19.04.0.pom