> That's not possible because there are no Quarkus dependencies in that module, > so you can't annotate with @WithDefault, for example.
I mentioned smallrye-config, not Quarkus, so you _can_ annotate those. On Thu, Jul 31, 2025 at 6:34 PM Yufei Gu <flyrain...@gmail.com> wrote: > > +1. Thanks Alex for driving this. Other than the benefits discussed like > removing the duplicated config classes like > `QuarkusStorageCredentialCacheConfig`, or removing `.quarkus.` in the > package name, we can finally put classes like S3AccessConfig > and StsClientsPool into the right package. > > Yufei > > > On Thu, Jul 31, 2025 at 8:45 AM Eric Maynard <eric.w.mayn...@gmail.com> > wrote: > > > The project already *has* adopted Quarkus for good, so I think making the > > module structure reflect that is fine. In addition to the configuration > > issue, which is significant, I think cutting down on the number of modules > > we publish is a noble goal. > > > > —EM > > > > On Fri, Aug 1, 2025 at 00:43 Alexandre Dutra <adu...@apache.org> wrote: > > > > > 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 > > > > >
