`com.clickhouse/clickhouse-jdbc$http` has CLI and GRPC modules as transitive dependencies

[slvrtrn]

While working on the Metabase plugin that uses the updated JDBC driver now, I noticed that if I use com.clickhouse/clickhouse-jdbc$http as a dependency, the resulting JAR also includes shaded GRPC and CLI modules:

  Write :clickhouse :oss uberjar -> /home/serge/work/metabase/resources/modules/clickhouse.metabase-driver.jar
    Determine which dependencies to include
      INCLUDE com.clickhouse/clickhouse-cli-client$shaded
      INCLUDE com.clickhouse/clickhouse-grpc-client$shaded
      INCLUDE com.clickhouse/clickhouse-http-client$shaded
      INCLUDE com.clickhouse/clickhouse-jdbc$http
      INCLUDE com.google.code.gson/gson

and the resulting JAR is way too big: around 20M

having CLI and GRPC explicitly excluded (example in Clojure's deps.edn)

 :deps
 {com.clickhouse/clickhouse-jdbc$http
  {:mvn/version "0.3.2-patch11"
   :exclusions [com.clickhouse/clickhouse-cli-client$shaded
                com.clickhouse/clickhouse-grpc-client$shaded]}}

reduces the final size to 1.2M, i.e. it is 19x times less.

Maybe GRPC and CLI could be released as separate modules, so we can plug them in instead of excluding them when needed?

[zhicwu]

Thanks @slvrtrn. Yes, it's cleaner to create separate modules. But there'll be modules like clickhouse-jdbc-http, clickhouse-jdbc-grpc, clickhouse-jdbc-cli, and clickhouse-jdbc-all etc., which might be confusing. That's why I suggested to exclude all dependencies when you specify classifer :)

As to Metabase driver, I think it's probably better to use all instead of http, as it gives user more options to connect to ClickHouse, if the size is not a big concern ;)

[slvrtrn]

@zhicwu, thanks for the suggestion! Indeed, we should try TCP/Native in the Metabase plugin.