LuciferYang commented on PR #12414: URL: https://github.com/apache/gravitino/pull/12414#issuecomment-5311118513
Done in e321b6639. Agreed it was a second dispatch, and the version package is gone. Each version module now declares its own `SparkCatalogs` at the same FQN with compile-time class references, and the driver plugin reads the table from whichever jar is on the classpath. What stays shared is provider to catalog kind, as a `SparkCatalogKind` enum: that mapping is the same on every version, and it is where the `jdbc-*` prefix rule lives. Adding a Spark version no longer touches shared code, and the misleading warning goes with the version lookup, since a jar can now only name catalogs it contains. One entry cannot be a class reference: Paimon publishes no `paimon-spark-3.5_2.13`, so the Scala 2.13 build compiles that package out and a `.class` reference breaks it. It stays a string in `v3.5`'s own `SparkCatalogs`, added only when the class is present. `v4.0` has no Paimon entry. `TestCatalogNameAdaptor` is replaced by `TestSparkCatalogKind` for the provider mapping, plus `TestSparkCatalogs`, which compiles into both modules and asserts what must hold on every version rather than a fixed list of names: each declared class resolves and is a `BaseCatalog`, and the five kinds every build ships are present. The names are the compiler's job now. Verified: unit tests at 123 cases on 3.5 Scala 2.12, 120 on 2.13, 120 on 4.0; `SparkHiveCatalogIT40` 51 cases and `SparkPaimonCatalogFilesystemBackendIT35` 36 as end-to-end registration checks; both runtime jars rebuilt with no `connector/version/` entries. No failures. -- 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]
