Bump dev.zarr:jzarr to 0.4.2

[sbesson]

Downstream consumers of this reader have been failing to build it over the last few days - see https://merge-ci.openmicroscopy.org/jenkins/job/BIOFORMATS-image/372/console or https://github.com/ome/openmicroscopy/actions/runs/6666558502/job/18118363098 with

Error:  Failed to execute goal on project OMEZarrReader: Could not resolve dependencies for project ome:OMEZarrReader:jar:0.3.2-SNAPSHOT: Failed to collect dependencies at dev.zarr:jzarr:jar:0.4.0 -> edu.ucar:cdm-core:jar:5.3.3: Failed to read artifact descriptor for edu.ucar:cdm-core:jar:5.3.3: Could not transfer artifact edu.ucar:cdm-core:pom:5.3.3 from/to snap-repo-public (https://snap-build-server.tilaa.cloud/nexus/repository/snap-maven-public/): transfer failed for https://snap-build-server.tilaa.cloud/nexus/repository/snap-maven-public/edu/ucar/cdm-core/5.3.3/cdm-core-5.3.3.pom: PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed: NotAfter: Fri Oct 27 10:08:03 UTC 2023 -> [Help 1]

The source of the issue is the expiration of the certificate of the repository declared in https://github.com/zarr-developers/jzarr/blob/d4f85aa20816a1a0137ad3fa5a5a8513fd790c6e/pom.xml#L155-L167 and used to retrieve the netcdf dependency of jzarr.
This is not specific to zarr.dev:jzarr as the repository was introduced in the original repository in bcdev/jzarr@020f964.

It's unclear why this repository has been chosen and whether the certificates will be fixed. As a stopgap, this commit declares the standard Unidata repository used across the rest of Bio-Formats in this consumer repository. This should allow the builds to use this repository to fetch the netcdf dependency.
If the problem persists, the same change could be opened against https://github.com/zarr-developers/jzarr /cc @joshmoore

[joshmoore]

Thanks, @sbesson. If the official unidata repo works, I don't see why we wouldn't use it. The only reason I can think of is that this cloud repo was "the" place to get snapshots.

[joshmoore]

In trying to release zarr-developers/jzarr#15 today as 0.4.1, I ran into the same issue and therefore I'm now releasing zarr-developers/jzarr#17 as 0.4.2 😄

[sbesson]

In trying to release zarr-developers/jzarr#15 today as 0.4.1, I ran into the same issue and therefore I'm now releasing zarr-developers/jzarr#17 as 0.4.2 😄

Should the change here be replaced by a bump to dev.zarr:jzarr:0.4.2 instead?

[joshmoore]

It's now up on https://central.sonatype.com/artifact/dev.zarr/jzarr/ if you want to try. I thought that it was necessary to list in each repo, but perhaps something changed.

[sbesson]

Looks like bumping to 0.4.2 was sufficient to fix the build even after disabling the Maven cache.

I thought that it was necessary to list in each repo, but perhaps something changed.

I recalled something similar about repositories defined in the pom.xml of the project dependencies not being inherited. Possibly that would only apply if this project was explicitly depending on netcdf and unidata.releases would need to be declared. 7613b64 reverts the addition of the repository but I can reinclude it if we want to be defensive.

[joshmoore]

LGTM