Hi Romain, > pluggability at *runtime* [...]
I believe this will still require a custom downstream build to add optional jars to the server, right? One approach, I was thinking about is making a self-building docker image, where the user provides options as env. variables and a Quarkus build will happens inside docker and produces the final customized docker image per user selection. The user will not need to worry about Gradle specifics; all of that will be inside the container. Cheers, Dmitri. On Wed, Mar 18, 2026 at 7:22 PM Romain Manni-Bucau <[email protected]> wrote: > Hi, > > As an end users I have a small feedback on that topic: > > 1. it is unlikely we rebuild polaris to get federation (we'd federate > poalris to make it clear) - with hive catalog for now > 2. hive integration with polaris is not fully aligned with spark which has > shihms so there is already this classloader or alternative need > > > what can be envisionned if you do not want to go with classloaders is real > pluggability at *runtime* (like any real CDI application) or worse case > using a ServiceLoader (even if weird in a CDI stack since the SPI is CDI > impl itself). > > so from my small window a valid option is to make polaris runtime friendly > (vs build friendly which is not a solution for a product) and optionally > enable classloading (just needs to be a tree like > > https://github.com/Talend/component-runtime/blob/master/container/container-core/src/main/java/org/talend/sdk/component/container/ContainerManager.java > ). > the classloader support can even be made in a runtime extension which does > load a configuration to load other extension so you get the best of both > worlds, but point is you cant request users to *build* for a webapp > ultimately delivered as a docker image - I know apache is just about > sources but nobody consumes it this way (except vendors when they fork but > hopefully it is a few end users). > > hope it makes sense > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > Le mer. 18 mars 2026 à 23:18, Dmitri Bourlatchkov <[email protected]> a > écrit : > > > Hi All, > > > > Good point about modeling federation implementations similarly to > pluggable > > persistence implementations. > > > > I'm not sure about meddling with ClassLoaders in Polaris. I'd prefer to > > leverage the existing Quarkus-based integration of multiple modules into > a > > single runtime env. (current state). > > > > Downstream project will have the ability to elect which modules to use > > at build time. > > > > Cheers, > > Dmitri. > > > > On Wed, Mar 18, 2026 at 2:42 AM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > Hi everyone, > > > > > > "Classloader" is a fair and valid point. I have shared this perspective > > in > > > the past and discussed it with Nandor as well: I believe federation > > should > > > utilize a "plugin" mechanism, similar to how persistence is handled. > > > > > > By adopting this approach, each plugin (such as HMS) is in its own > > module, > > > and would be responsible for managing its own dependencies and shading. > > > > > > Regards, > > > JB > > > > > > On Wed, Mar 18, 2026 at 12:37 AM Yufei Gu <[email protected]> > wrote: > > > > > > > Federation seems like the strongest candidate given the dependency > > > surface. > > > > For example, Trino-style classloader isolation could help when > > conflicts > > > > arise (e.g., Hadoop or Guava across different federation > > > implementations). > > > > That said, I’d suggest introducing this only once we actually hit > such > > > > issues. Until then, keeping things simple with proper modularization > > may > > > be > > > > the better tradeoff. WDTY? > > > > > > > > Yufei > > > > > > > > > > > > On Tue, Mar 17, 2026 at 2:00 PM Madhan Neethiraj <[email protected]> > > > > wrote: > > > > > > > > > > we need to be careful about is proper modularization to control > > > > > dependency scope growth. > > > > > > > > > > I share this concern; it is applicable for any extension like > > > > authorizers. > > > > > Having a built-in support for isolation of extension specific > > > > dependencies > > > > > will significantly reduce/eliminate complexities in handling > > potential > > > > > library conflicts and avoid impact to Polaris core due to > > dependencies > > > > > dragged by extensions. Trino's plugin model seems to be a good > > > reference > > > > - > > > > > 1) and 2). > > > > > > > > > > Thanks, > > > > > Madhan > > > > > > > > > > 1) https://trino.io/docs/current/installation/plugins.html > > > > > 3) https://trino.io/docs/current/develop/spi-overview.html > > > > > > > > > > > > > > > On 3/17/26, 1:30 PM, "Prashant Singh via dev" < > > [email protected] > > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > > > > > > +1 to this. I would also recommend thinking about this from an > > > interface > > > > > POV to have BaseMetastoreCatalog (from Apache Iceberg) as a way to > > > > > integrate, with a defined connection object that can feed the > > > connection > > > > to > > > > > BQ or Glue (perhaps a standard key-value prep) > > > > > and the dependencies can be added accordingly. > > > > > > > > > > > > > > > Thanks, > > > > > Prashant Singh > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Mar 17, 2026 at 12:08 PM Dmitri Bourlatchkov < > > [email protected] > > > > > <mailto:[email protected]>> > > > > > wrote: > > > > > > > > > > > > > > > > Hi Joy, > > > > > > > > > > > > I suppose Polaris will be the REST API + AuthZ layer on top of > > > > > > BigQueryMetastoreCatalog, right? How do you envision this? > > > > > > > > > > > > In general, I think it's going to be a useful contribution. > > > > > > > > > > > > From my POV, the only technical issue we need to be careful about > > is > > > > > > proper modularization to control dependency scope growth. I > imagine > > > > some > > > > > > downstream projects may want to opt in/out of > > > BigQueryMetastoreCatalog > > > > > and > > > > > > its transitive dependencies at their own discretion. > > > > > > > > > > > > Cheers, > > > > > > Dmitri. > > > > > > > > > > > > On 2026/03/17 18:19:34 Joy wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm Joy. We use BigQueryMetastoreCatalog for Iceberg on GCP and > > > want > > > > to > > > > > > use > > > > > > > Polaris as a catalog gateway. I see federation currently > supports > > > > REST > > > > > > and > > > > > > > HMS. > > > > > > > > > > > > > > Would there be interest in supporting other native Iceberg > > catalogs > > > > > like > > > > > > > BQMS or Glue? I've been working on a prototype for BQMS > following > > > the > > > > > HMS > > > > > > > pattern and would be happy to contribute it if I'm successful. > > > > > > > > > > > > > > Regards, > > > > > > > Joy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
