j1wonpark commented on code in PR #4069:
URL: https://github.com/apache/amoro/pull/4069#discussion_r2756483500
##########
amoro-ams/pom.xml:
##########
@@ -510,7 +510,6 @@
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>${guava.version}</version>
Review Comment:
Hi @czy006, thanks for reporting the Paimon Hive Catalog issue — that's very
helpful!
This fix should actually resolve the Paimon case as well. Let me explain why.
I decompiled the `paimon-bundle` JAR and traced the runtime call path:
1. **Paimon's own Guava is fully shaded** — relocated to
`org.apache.paimon.shade.guava30.com.google.common.*`, so Paimon's internal
code has no dependency on unshaded Guava.
2. **However, Paimon's `HiveCatalog` references unshaded
`org.apache.hadoop.hive.conf.HiveConf` directly:**
```
private final org.apache.hadoop.hive.conf.HiveConf hiveConf;
```
`HiveConf` is **not** bundled inside `paimon-bundle` — it's resolved from
the amoro-ams classpath at runtime.
3. **`HiveConf` internally uses unshaded Guava** (e.g.,
`com.google.common.collect.ImmutableMap`), which is exactly the same root cause
as the Iceberg case.
So the call chain is:
```
PaimonCatalogFactory.create()
→ CatalogFactory.createCatalog()
→ Paimon HiveCatalog (uses shaded guava30 internally ✅)
→ org.apache.hadoop.hive.conf.HiveConf (from amoro-ams classpath)
→ com.google.common.collect.ImmutableMap ❌ (NoClassDefFoundError
without this fix)
```
By promoting Guava from `test` to `compile` scope in `amoro-ams`, the
unshaded Guava classes become available on the runtime classpath, resolving the
issue for **both** Iceberg and Paimon Hive Catalogs.
Regarding the shared package concern — there is no actual conflict:
- **Amoro's own code** → `org.apache.amoro.shade.guava32.com.google.*`
(relocated)
- **Paimon's internal code** →
`org.apache.paimon.shade.guava30.com.google.*` (relocated)
- **Hive / Iceberg** → `com.google.common.*` (unshaded, provided by this fix)
- All three namespaces coexist without collision.
- All transitive Guava dependencies are already excluded via `<exclusion>`,
so only a single unshaded Guava version (`${guava.version}`) exists on the
classpath.
That said, if you are experiencing a specific error that this fix does not
resolve, could you share the details (stack trace, environment, etc.)? I'd be
happy to investigate further and work on a solution together.
Thanks again for the feedback! 🙏
--
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]
