Hi Robert,

> I think we can get away by having the smallrye-config annotations on the 
> "parent" interface.

That's not possible because there are no Quarkus dependencies in that
module, so you can't annotate with @WithDefault, for example.

Indeed merging those two modules would mean that we're adopting
Quarkus for good, but I think that at this point, nobody would object.

In this merge, we could also remove the ".quarkus." bits from package
names and remove the "Quarkus" prefix of many classes. I think this
would result in a much more readable code, but that's just my opinion
:-)

My long-term vision is that, after the merge, we could also consider
splitting the resulting "uber-module" into smaller, concern-specific
modules like "polaris-service-auth", "polaris-service-telemetry",
"polaris-service-events", etc. This approach would make it much
simpler for integrators to implement their own customizations (and
brings no downsides for regular users).

But this needs to be done in two steps: first, merge the current two
modules; then, split the result.

Thanks,
Alex

On Thu, Jul 31, 2025 at 5:22 PM Robert Stupp <sn...@snazy.de> wrote:
>
> Is the issue here just the configuration types or is there more?
> For the config types, I think we can get away by having the
> smallrye-config annotations on the "parent" interface.
>
> My concern is that polaris-runtime-service is rather the Quarkus specifics.
> CDI is great, just Quarkus isn't the only enterprise-CDI runtime.
> Spoiler: I do *not* think that Polaris should move away from Quarkus.
>
> But for sole testing purposes Quarkus is quite expensive, too
> expensive IMO to make it a necessity for all tests.
> Sure, not all tests have to be `@QuarkusTest`s, but I could imagine
> that there will be tests that do not need Quarkus are annotated as
> such.
>
> On Thu, Jul 31, 2025 at 12:19 PM Alexandre Dutra <adu...@apache.org> wrote:
> >
> > Hi all,
> >
> > The polaris-service-common module is a reminiscence of the times where
> > we were still supporting two runtimes.
> >
> > I think it has now become obsolete, and could be merged into
> > polaris-runtime-service.
> >
> > One annoyance that polaris-service-common brings is with configuration
> > classes that have to exist in both modules (e.g.
> > AuthenticationConfiguration vs QuarkusAuthenticationConfiguration).
> >
> > Would we be OK with this merge? If so I'm happy to provide the PR.
> >
> > Thanks,
> > Alex

Reply via email to