XuQianJin-Stars commented on code in PR #3256:
URL: https://github.com/apache/fluss/pull/3256#discussion_r3214230848
##########
fluss-flink/fluss-flink-common/pom.xml:
##########
@@ -95,6 +95,24 @@
<scope>provided</scope>
</dependency>
+ <!-- Hudi -->
Review Comment:
Looking at the existing modules:
- **Paimon** is `import`-ed directly in `LakeFlinkCatalog` /
`LakeTableFactory`, so it requires a pom dep.
- **Iceberg** is loaded via
`Class.forName("org.apache.iceberg.flink.FlinkDynamicTableFactory")` in
`LakeTableFactory#getIcebergFactory()`. **There is no Iceberg dep in
`fluss-flink-common/pom.xml`** — `fluss-flink-common` stays decoupled from
Iceberg, and the actual jars come from `plugins/iceberg/*` at runtime.
- **Hudi** in this PR has no Java references at all (`git grep
"org.apache.hudi" -- '*.java'` returns 0 hits), yet adds a hard pom dep to
`hudi-flink1.20-bundle` — a shaded uber-bundle that re-bundles
hadoop/parquet/avro/jackson/guava. This is the worst of both worlds: dead
dependency + classpath pollution for every downstream that consumes
`fluss-flink-common`.
Suggestion: When real Hudi-Flink integration lands, follow the Iceberg
pattern (`Class.forName`) and keep concrete Hudi artifacts only in
`fluss-lake-hudi/pom.xml`.
--
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]
