I think having prebuilt pluggables is probably a good way forward. This could also separate out some classpath concerns as well since users wouldn't necessarily have to bundle plugins with dependencies they don't like on the classpath.
So +1 for runtime selection and I would prefer we actually build the plugins separately too in the future. On Fri, Dec 13, 2024 at 11:48 AM Dmitri Bourlatchkov <dmitri.bourlatch...@dremio.com.invalid> wrote: > Hi All, > > Currently using Polaris with a particular backend apparently requires > special build-time options. > > For example, targeting EclipseLink with PostgreSQL needs > "-PeclipseLink=true -PeclipseLinkDeps=org.postgresql:postgresql:42.7.4" at > build (!) time [1]. > > This email is to discuss our approach to supporting various pluggable > modules in general. > > Do we want to continue with the approach that users of a particular > database need to rebuild Polaris for that backend? > > IMHO, this approach is impractical. > > I'd like to propose that the standard build contains artifacts for all > supported backends and the admin user chooses what backend is to be used > via runtime configuration parameters. > > Given the current state of the code, we could probably pre-build for > In-Memory and EclipseLink with H2 and PostgreSQL, with additional backends > being worked on as discussed elsewhere. So the admin user will have three > Persistence options for now. > > WDYT? > > Thanks, > Dmitri. > > [1] https://polaris.apache.org/in-dev/unreleased/metastores/ >
