Hi all,
In anticipation of the upcoming 2.26 release I’d like you to notice a mistake I’ve made related to dependency version convergence for the transitive netty dependencies coming from
- cog-rangereader-s3
- cog-rangereader-azure
- gwc-azure-blob
In their respective builds, all of them are using netty:4.1.113.Final, as of imageio-ext:1.4.13 and gwc:1.26. So that’s fine and they’re all working with that version of netty as per their respective integration tests.
But when checking the dependencies on GeoServer, they carry over their original netty versions, so we get mixed netty dependency versions:
- cog-rangereader-s3 → 4.1.112.Final
- cog-rangereader-azure → 4.1.110.Final
- gwc-azure-blob → 4.1.110.Final
This means if you needed to include both the cog-rangereader-s3 and cog-rangereader-azure plugins, you’ll end up with mixed versions of the same netty dependencies in the classpath.
This should not really be a problem for a regular GeoServer deployment as since the split of the imageio-ext cog dependency into per-cloud-provider modules, it’s unlikely that someone will require both the s3 and azure cog range readers.
My mistake was thinking the netty bom like here and here[2] was enough, but what I should have done additionally is to exclude the netty dependencies and add them explicitly.
In GeoServer Cloud this is a problem but it’s fixed already with the maven dependency convergence rule we can keep on using.
So I just wanted to let you know I’ve made this mistake, and ask if we want to apply a workaround in GeoServer by adding the 4.1.113.Final netty bom to the root pom’s dependencyManagement section, or we leave it as is given it still fulfills the idea that cog rangereader plugins won’t be installed for multiple cloud providers?
Cheers,
camptocamp
···
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Gabriel Roldán
Geospatial Developer