search

glencoesoftware / raw2ometiff

Raw format to OME-TIFF converter
GNU General Public License v2.0
46 stars 20 forks source link

Bump dependencies to formats-bsd 6.10.1 and jzarr 0.3.5 #84

Closed sbesson closed 1 year ago

sbesson commented 1 year ago

Discovered while reviewing the dependency conflict https://github.com/glencoesoftware/NGFF-Converter

This change aligns the dependencies of raw2ometiff with the ones used in bioformats2raw 0.5.0

Should be amenable for an immediate patch release 0.3.2 as there is no functional or API change

sbesson commented 1 year ago 
* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not download httpservices-5.3.3.jar (edu.ucar:httpservices:5.3.3)
      > Could not get resource 'https://nexus.senbox.net/nexus/content/groups/public/edu/ucar/httpservices/5.3.3/httpservices-5.3.3.jar'.
         > Could not GET 'https://nexus.senbox.net/nexus/content/groups/public/edu/ucar/httpservices/5.3.3/httpservices-5.3.3.jar'.
            > peer not authenticated

is identical to the build failure on the HEAD of the base branch - see https://ci.appveyor.com/project/gs-jenkins/raw2ometiff/builds/44910893

This makes me wonder whether I should revert https://github.com/glencoesoftware/raw2ometiff/pull/83 and/or if we should declare a more suitable repository under HTTPS that serves these artifacts. For comparison, https://github.com/glencoesoftware/bioformats2raw/blob/v0.5.0/build.gradle is not using senbox. Thoughts @melissalinkert ?

melissalinkert commented 1 year ago

I think switching senbox to https://artifacts.glencoesoftware.com/artifactory/unidata-releases is fine.

Upgrading jzarr will also require changes in the tests, since the getNested() API in jzarr 0.3.3-gs-SNAPSHOT is being used.

sbesson commented 1 year ago

@melissalinkert pushed. In addition to updating the tests, I also had to bump the version of bioformats2raw used for testing to 0.5.0 to be compatible with the jzarr version used by the library.

With bioformats2raw 0.5.0 behind us, I think makes sense to test the conversion pipeline using bioformats2raw 0.5.x but that means we are no longer testing the compatibility with data generated by bioformats2raw 0.3.x. Happy to discuss if we believe this is creating a testing gap we should address.

chris-allan commented 1 year ago

I'm not particularly worried about continuing to test with bioformats2raw 0.3.0. We have released versions of raw2ometiff that are known to work with that data, and there isn't really any advantage to upgrading raw2ometiff out of step with bioformats2raw.

Agreed.