+1 to unblocking 1.11 and 1.10.2 releases. The proposal here seems to be to exclude both kafka-connect-runtime and open-api (iceberg-rest-fixture docker) from the release. Is the idea to then do a follow up patch release to fix forward?
I want these PRs up to fix the LICENSE for all cloud bundles + spark and flink. These PRs should unblock the release. - AWS https://github.com/apache/iceberg/pull/16196 - Azure https://github.com/apache/iceberg/pull/16181 - GCP https://github.com/apache/iceberg/pull/16182 - Spark https://github.com/apache/iceberg/pull/16215 - Flink https://github.com/apache/iceberg/pull/16216 I also started looking at the open-api issue ( https://github.com/apache/iceberg/pull/16214). I would love to get it fixed before the release, but it's not a blocker. Thanks, Kevin Liu On Fri, May 1, 2026 at 11:35 PM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Fokko, > > I agree. I think we should look at the Gradle configuration. Currently, > the test-fixtures artifact is being published to Maven without a classifier > as a "pure" jar (loosing test-fixtures classifier), even though it is not > supposed to be published at all. > > I flagged this in the release thread, and I believe we should update the > Gradle behavior to ensure this artifact is not published. > > Regards, > JB > > On Fri, May 1, 2026 at 11:08 AM Fokko Driesprong <[email protected]> wrote: > >> Thanks Ryan for addressing this. >> >> I agree that we shouldn't release the the Open-API jar, in line with the >> publication section on the release doc: >> http://apache.org/legal/release-policy.html#publication. The Open-API >> jar build a docker image, which is ment for development purposes only. For >> example, when working on server side planning in the reference Java >> implementation, we can test against this in PyIceberg/Iceberg-Rust/etc >> after the nightly build is published. But I think we should not publish the >> jar itself (at this point at least). >> >> Kind regards, >> Fokko >> >> On 2026/05/01 08:20:27 Péter Váry wrote: >> > +1 >> > >> > John Zhuge <[email protected]> ezt írta (időpont: 2026. máj. 1., P, >> 4:34): >> > >> > > +1 (non-binding) >> > > >> > > On Thu, Apr 30, 2026 at 7:08 PM roryqi <[email protected]> wrote: >> > > >> > >> +1, agree! >> > >> >> > >> Steve <[email protected]> 于2026年5月1日周五 07:02写道： >> > >> > >> > >> > +1 , agree to unblock the 1.11 and 1.12 releases first and revisit. >> > >> > >> > >> > Thanks, >> > >> > Steve >> > >> > >> > >> > On Thu, Apr 30, 2026 at 12:45 PM Jean-Baptiste Onofré < >> [email protected]> >> > >> wrote: >> > >> > > >> > >> > > Hi Ryan, >> > >> > > >> > >> > > I agree with this approach. It is perfectly aligned with the >> points I >> > >> mentioned a while ago. >> > >> > > >> > >> > > Regards, >> > >> > > JB >> > >> > > >> > >> > > On Thu, Apr 30, 2026 at 7:49 PM Ryan Blue <[email protected]> >> wrote: >> > >> > >> >> > >> > >> Hi everyone, >> > >> > >> >> > >> > >> I have a quick update on LICENSE issues that are currently >> blocking >> > >> 1.11 and 1.10.2. Also, sorry if you got this twice, but it looks >> like it >> > >> didn't go through the first time. >> > >> > >> >> > >> > >> TL;DR: I think we should: >> > >> > >> >> > >> > >> Hold off on adding Kafka Connect to the release process >> > >> > >> Remove the iceberg-open-api-test-fixtures-runtime Jar from >> releases >> > >> > >> >> > >> > >> The background is that over the last few weeks, we found two >> fairly >> > >> large leaks that added transitive dependencies into Iceberg runtime >> Jars >> > >> (fixed by #15655 and #15858). As a result, Russell added a new way >> to track >> > >> and validate the dependencies included in our published artifacts. >> To make >> > >> sure the new checks are correct, I’ve been going through to validate >> the >> > >> LICENSE/NOTICE files against the dependency list. Unfortunately, >> there are >> > >> more problems. >> > >> > >> >> > >> > >> The first problem is with our Kafka Connect distribution. There >> are >> > >> two zip distributions, a Hive and a non-Hive version. Robin has been >> > >> working on getting these published as part of our release process in >> > >> #15212. The non-Hive distribution is very large and has some >> dependencies >> > >> that may not need to be there, like Apache Commons Jars that aren’t >> used in >> > >> Iceberg (and would be provided by KC if needed?). #16147 is a draft >> with >> > >> some of the non-Hive changes. The Hive distribution has about 100 >> more Jars >> > >> than non-Hive, and includes many dependencies that are almost >> certainly >> > >> unnecessary, like 3 hadoop-mapreduce-* Jars. My recommendation is to >> hold >> > >> off on making Kafka Connect part of releases until the license >> issues are >> > >> solved. >> > >> > >> >> > >> > >> Another issue is the open-api module. We added this to the Java >> > >> build to verify the REST catalog spec, but then added tests and >> fixtures >> > >> for validating REST implementations. #11279 added a runtime Jar for >> to run >> > >> a test service, but most PMC members I’ve talked to about it didn’t >> know >> > >> that we have been publishing it — and have been since 1.7. This >> runtime Jar >> > >> indiscriminately bundles far more libraries than it needs, like the >> cloud >> > >> provider libs, Hadoop common, JUnit, Jetty, and others. The Jar is >> 200+ MB. >> > >> My recommendation is to remove this Jar from publication to unblock >> > >> releases. >> > >> > >> >> > >> > >> As a general rule, when we are considering adding a new runtime >> > >> distribution to the project, we need to check that it is something >> we need >> > >> to do (vs an easy alternative), and if it is, then minimize the >> > >> dependencies included to only those required to run it. Once that’s >> done, >> > >> we need to document the dependencies in LICENSE and NOTICE and, as of >> > >> #15855, ensure that the bundled dependencies are tracked in a >> > >> runtime-deps.txt file. >> > >> > >> >> > >> > >> I think the priority right now is to unblock the 1.11 and 1.10.2 >> > >> releases. We can do that by not releasing these artifacts. After >> that, I >> > >> think we need to verify for all of these that they are needed, have >> minimal >> > >> included dependencies, and then document those dependencies. For >> example, >> > >> do we need a Kafka Connect Hive distribution or is the REST catalog >> version >> > >> enough? Does everyone agree that this is the right path forward? >> > >> > >> >> > >> > >> Thanks, >> > >> > >> >> > >> > >> Ryan >> > >> >> > > >> > > >> > > -- >> > > John Zhuge >> > > >> > >> >
