search

ome / ZarrReader

Other
5 stars 8 forks source link

Bump dev.zarr:jzarr to 0.4.2 #66

Closed sbesson closed 10 months ago

sbesson commented 10 months ago

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 https://github.com/bcdev/jzarr/commit/020f964fa729779f8cd07a6bd3b11e1fa2b2a0b1.

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 commented 10 months ago

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 commented 10 months ago

In trying to release https://github.com/zarr-developers/jzarr/pull/15 today as 0.4.1, I ran into the same issue and therefore I'm now releasing https://github.com/zarr-developers/jzarr/pull/17 as 0.4.2 :smile:

sbesson commented 10 months ago

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

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

joshmoore commented 10 months ago

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 commented 10 months ago

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.