Bump jackson libs to 2.20.0

[dominikl]

Trying to resolve version conflict with omero-zarr-pixel-buffer (#11 will use jackson libs version 2.20.0); omero-server comes with 2.14.2, which I tracked down to ome-common-java (omero-server -> bioformats -> ome-common-java), although it's actually not used in the server or in bioformats

ome-common-java/pom.xml

Line 128 in 5fd163e

<version>2.14.2</version>

Could this be bumped to 2.20.0? As far as I can see it's used in bioformats2raw/raw2ometiff, image-region microservice and Insight: https://github.com/search?q=org%3Aome%20import%20com.fasterxml.jackson&type=code . It should be backwards compatible with 2.14, so I wouldn't expect any changes needed.

[melissalinkert]

@dominikl, is this now ready for review or were there any more commits planned?

[dominikl]

Yes, ready for review. Just wasn't sure who to add as reviewer.

[melissalinkert]

I don't have any particular objection to this and builds have continued to pass with this included (e.g. https://bf-testing-results.s3.amazonaws.com/2025/2025-10-21/build-status.log). Requesting review from @sbesson too though, as I don't have a good sense of what the impact is in OMERO (if any).

[sbesson]

I also don't have any objection per se on the version bump but it might be worth discussing the intent and the expectations. Having reviewed the history in the scope of this repository:

• the jackson dependency was originally introduced as a transitive dependency of minio as part of the initial S3 effort in Add S3Handle #33
• the version of this library was selectively excluded in Bump jackson dependencies to 2.9.8 #63 and updated in Bump jackson dependencies to 2.14.2 #76. The primary motivation was development and specifically the ability to builds and combine different components for OMERO.server- Build combined openmicroscopy#6328
• from https://github.com/search?q=org%3Aome+import+com.fasterxml.jackson&type=code, only a handful set of repositories depend directly on the jackson libraries, primarily the repositories that are dealing with OME-Zarr and OMERO.insight
• importantly, org.openmicroscopy:ome-common itself has no direct dependency on jackson

The latter points makes me consider whether managing the jackson version at the level of this component is a viable approach. In some ways, this strategy is inheriting the concepts of a Maven Bill of Materials. However, this component is not a BOM and the OME Java stack is currently not architected to adhere to such principles. The opposite perspective is that downstream repositories should be responsible for declaring their dependencies and versions, overriding versions declared by upstream components as needed. I would propose to us an upcoming Formats meeting so that we can review and discuss the problem we are trying to solve and evaluate the various strategies.