hudi-agent commented on code in PR #20020:
URL: https://github.com/apache/hudi/pull/20020#discussion_r4078291473
##########
packaging/hudi-gcp-bundle/pom.xml:
##########
@@ -99,7 +99,21 @@
<include>org.apache.hudi:hudi-hive-sync</include>
<include>org.apache.hudi:hudi-gcp</include>
<include>org.apache.parquet:parquet-avro</include>
- <include>com.google.cloud:google-cloud-bigquery</include>
+ <!-- Google Cloud SDK -->
+ <include>com.google.cloud:*</include>
Review Comment:
🤖 The tree shows `com.google.guava:guava:31.1-jre` (plus
`failureaccess`/`listenablefuture`) in the closure, but no include matches that
groupId — google-cloud-storage, gax and grpc all use Guava heavily, so the
bundle still depends on whatever Guava the host classpath has (Hadoop/Spark
often ship 27 or older). Could you check whether the GCS lock client actually
loads without bundling (and relocating) Guava?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
##########
packaging/hudi-gcp-bundle/pom.xml:
##########
@@ -99,7 +99,21 @@
<include>org.apache.hudi:hudi-hive-sync</include>
<include>org.apache.hudi:hudi-gcp</include>
<include>org.apache.parquet:parquet-avro</include>
- <include>com.google.cloud:google-cloud-bigquery</include>
+ <!-- Google Cloud SDK -->
+ <include>com.google.cloud:*</include>
+ <include>com.google.api:*</include>
+ <include>com.google.apis:*</include>
+ <include>com.google.api-client:*</include>
+ <include>com.google.api.grpc:*</include>
+ <include>com.google.auth:*</include>
+ <include>com.google.code.gson:*</include>
+ <include>com.google.http-client:*</include>
+ <include>com.google.oauth-client:*</include>
+ <include>com.google.protobuf:*</include>
+ <include>io.grpc:*</include>
Review Comment:
🤖 These broad wildcards make the bundle contents a function of whatever
`libraries-bom` drags in — `com.google.cloud:*` now adds pubsub,
bigquerystorage and monitoring, and `io.grpc:*` adds
xds/alts/grpclb/netty-shaded. Would it be worth enumerating the artifacts the
bundle actually needs so a future BOM bump can't silently change or bloat the
jar?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
##########
packaging/hudi-gcp-bundle/pom.xml:
##########
@@ -99,7 +99,21 @@
<include>org.apache.hudi:hudi-hive-sync</include>
<include>org.apache.hudi:hudi-gcp</include>
<include>org.apache.parquet:parquet-avro</include>
- <include>com.google.cloud:google-cloud-bigquery</include>
+ <!-- Google Cloud SDK -->
+ <include>com.google.cloud:*</include>
+ <include>com.google.api:*</include>
+ <include>com.google.apis:*</include>
+ <include>com.google.api-client:*</include>
+ <include>com.google.api.grpc:*</include>
Review Comment:
🤖 hudi-gcp depends on
`com.google.cloud.bigdataoss:gcs-connector`/`gcsio`/`util` and
`com.google.flogger:*`, and neither groupId is matched here — yet their
transitive tail (opencensus-impl, google-cloud-monitoring) does get pulled in
by the new wildcards. Was leaving the connector itself out intentional (assumed
cluster-provided), or is it part of the missing GCS runtime?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
--
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]
