FrankChen021 commented on PR #20341: URL: https://github.com/apache/druid/pull/20341#issuecomment-5674360259
[Codex dependency triage for exact head `1f9a49113f56b2730bf829e75c78bb3a7eed1861` / base `6a8cc4a06b53792ee58e86af2bf9b8eb5376ed72`] This dependency-only bump is not compatible with the Druid consumers in `kubernetes-overlord-extensions`: - `DruidKubernetesVertxHttpClientFactory` extends Fabric8 7.9.0 `kubernetes-httpclient-vertx` (the Vert.x 4 client) and uses `io.vertx.core.spi.resolver.ResolverProvider`. With Vert.x 5.1.8, that package is absent; compilation fails at lines 27, 81, 84, 99, and 101. The same deterministic compile failure appears in CodeQL Java, all 9 unit shards, all 4 QTest shards, and web checks. - Static Maven, strict compilation, OpenRewrite, packaging, and Docker jobs independently fail Enforcer because Vert.x 5.1.8 brings Netty 4.2.18.Final and tcnative 2.0.84.Final while Druid manages Netty 4.2.17.Final and tcnative 2.0.81.Final. - Fabric8 7.9.0 supplies a separate `kubernetes-httpclient-vertx-5` SPI and documents the Vert.x 4 and Vert.x 5 client modules as mutually exclusive. A correct migration needs dependency exclusions/module replacement plus factory, DNS, configuration, and runtime adaptation; it is not a bounded version-only repair. - Root `licenses.yaml` still records Vert.x 4.5.31, so the license inventory is stale for this target. The failures are PR-caused and deterministic; no reruns or push were justified. Compatibility is therefore INCOMPATIBLE, so I am closing this PR without approval or merge. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
