Update iceberg to 0.14.0

[danielcweeks]

Description

Iceberg client library and necessary changes to update to 0.14.0

Is this change a fix, improvement, new feature, refactoring, or other?

Dependency update

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

Client library

How would you describe this change to a non-technical end user or system administrator?

Related issues, pull requests, and links

Documentation

(X) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(X) No release notes entries required.
( ) Release notes entries required with the following suggested text:

# Section
*  ({issue}`issuenumber`)

[electrum]

We don't mention internal changes in release notes, so this shouldn't need one. If there are any user visible changes, we should mention those changes explicitly in a language the end user or administrator would understand.

[electrum]

Is this due to a version conflict?

[danielcweeks]

Yes, it appears there is a patch-level version dependency drift and the dependency enforcer caught it.

[danielcweeks]

I'm not sure if there's a better way to resolve this. This was the error (repeated for all iceberg dependencies):

Require upper bound dependencies error for org.slf4j:slf4j-api:1.7.32 paths to dependency are:
+-io.trino:trino-iceberg:391-SNAPSHOT
  +-org.apache.iceberg:iceberg-api:0.14.0
    +-org.slf4j:slf4j-api:1.7.32 (managed) <-- org.slf4j:slf4j-api:1.7.25

Iceberg is currently on 1.7.25

[electrum]

That's weird that it complains when a dependency has an older patch version. Note that it would be good to update Iceberg to the latest 1.7.36, since some of the SLF4J components have CVEs in 1.7.25 and stupid security scanners will flag the API JAR (even though it's not affected).

[danielcweeks]

We can definitely update in the next release (I'll create a PR for updating). There was a gradle update and it may have changed how these are declared which triggered the enforcer, but the dependency is valid and hasn't changed.

[electrum]

Can we file an issue for this in Iceberg? This resource should be namespaced to avoid conflicts, or drop it entirely (since Iceberg doesn't use the public suffix functions).

[danielcweeks]

I'll bring this up because the iceberg-build.properties was recently introduced and is included in all the artifact jars so that it's clear where any given jar came from.

The suffix list is a conflict from http client libraries, I believe.

[electrum]

Ah, I was thinking of the Guava com/google/thirdparty/publicsuffix package which is easy to miss since it's different than com/google/common. If Iceberg isn't the one shading the HTTP client, then there's nothing we can fix here.

For the iceberg-build.properties, you might consider putting it in META-INF, similar to how Maven does it with e.g., META-INF/maven/com.google.guava/guava/pom.properties.

[ebyhr]

Do you want to contribute to trinodb/docker-images as well?
https://github.com/trinodb/docker-images/blob/master/testing/spark3.0-iceberg/Dockerfile#L17

[danielcweeks]

Thanks for pointing this out @ebyhr, I'll open a PR

[danielcweeks]

@ebyhr docker image update is here #127

[electrum]

Thanks!