> Re: the `runtime/admin` module, let me try and clarify my point with an example: If we fold this module into `runtime/server`, downstream projects will not be able to reuse Admin CLI code because the `runtime/server` module itself is not meant to be reused.
Hi Dmitri, would you mind explaining how CLI code is reused and why the server module cannot be reused in that case? Yufei On Thu, Feb 19, 2026 at 10:20 PM Jean-Baptiste Onofré <[email protected]> wrote: > HI > > The question is also:do we have a case today of code reuse. If not, when > not starting simple, especially as we are "heading" to more atomic package. > If there's a "technical constraint" (due to jandex, or build time issue > with runtime/server), that's a good point (we should also investigate that, > we can talk with the Quarkus team to have a better understanding). > > If I understand the intent and purpose, if we don't have the case today, we > can keep it simple and refactore later. Anticipating is fine if we are sure > it will happen :) > I think I already said that in the past, so I say that again: we have to be > ready to change :) We can start with one approach and revisit later when we > actually have a concrete need. > > So, in order to move forward, I propose to keep the layout as it is > (because it's there) and we can revisit later. > It's what we did with admin and server: we started separated and then we > agreed to merge everything. > > I would also suggest reproducing and creating an issue about Quarkus build > "issue" on runtime/server (eventually to be able to reuse this module). > > Regards > JB > > On Fri, Feb 20, 2026 at 5:52 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Yufei, > > > > I would not mind folding polaris-runtime-common > > and polaris-runtime-test-common into some other module if the codebase > > allows it. These modules are indeed auxiliary and exist only to allow > > sharing code between other modules. > > > > Re: the `runtime/admin` module, let me try and clarify my point with an > > example: If we fold this module into `runtime/server`, downstream > projects > > will not be able to reuse Admin CLI code because the `runtime/server` > > module itself is not meant to be reused. > > > > What do you think about this use case? > > > > The main reason for not reusing `runtime/server` in downstream projects > is > > that there are some rather obscure Quarkus build issues when > > `application.properties` exist in multiple jar artifacts. I mentioned > that > > in [1]. I believe some downstream projects have already encountered this > > issue. > > > > [1] https://polaris.apache.org/in-dev/unreleased/downstream-build/ > > > > Cheers, > > Dmitri. > > > > On Fri, Feb 13, 2026 at 12:21 AM Yufei Gu <[email protected]> wrote: > > > > > Do we still need the modules polaris-runtime-common and > > > polaris-runtime-test-common in this new layout? These modules were > > > introduced purely because of the admin and server split. Now that we > are > > > converging toward a single distribution artifact, I am not sure they > > still > > > provide meaningful value. Both modules contain only a handful of > classes. > > > In particular, polaris-runtime-common currently holds just one class, > > which > > > feels like an over modularization. A module that exists solely to host > a > > > single class does not necessarily improve separation of concerns, and > may > > > instead increase structural overhead. > > > > > > As mentioned in the PR, splitting code into more modules does not > > > automatically lead to better modularity. In some cases, it can actually > > > make the system harder to understand and maintain. We should optimize > for > > > maintainability and clarity rather than strict structural purity. > > > Ultimately, the goal is to make the codebase easier to evolve and > > maintain. > > > If collapsing these modules simplifies the build and reduces cognitive > > load > > > without losing real isolation benefits, I think that would be a > > reasonable > > > direction. > > > > > > Yufei > > > > > > > > > On Thu, Feb 5, 2026 at 5:33 AM Alexandre Dutra <[email protected]> > > wrote: > > > > > > > Hi all, > > > > > > > > As I noted in the PR, I like Dmitri's layout proposal, as it produces > > > > a single artifact, while still keeping the code well organized. > > > > > > > > Thanks, > > > > Alex > > > > > > > > On Tue, Feb 3, 2026 at 5:10 PM Dmitri Bourlatchkov <[email protected] > > > > > > wrote: > > > > > > > > > > Hi Yufei, > > > > > > > > > > Refreshing this discussion a bit. > > > > > > > > > > To recap my overall thinking: > > > > > > > > > > I believe merging the Admin Tool and the Server in terms of > > > distribution > > > > > artifacts is a good idea. As you noted it will simplify license > > > > management > > > > > and the binary distribution. However, LICENSE changes in [3340] > seem > > to > > > > > require additional review and adjustments as Robert noted. > > > > > > > > > > In terms of source module layout, as I commented in [3340], I > believe > > > it > > > > is > > > > > still worth keeping the `runtime/admin` directory in the source > tree, > > > > build > > > > > a jar from it, but not a Quarkus application. Then the jar will be > > > > included > > > > > into the Quarkus build under `runtime/server`. > > > > > > > > > > The dir name `runtime/admin` might not be true to the "runtime" > claim > > > > after > > > > > this refactoring, but I guess we can rename it (while still keeping > > it > > > as > > > > > a separate source module) after it gets integrated into the server. > > > This > > > > is > > > > > just to reduce the PR complexity. > > > > > > > > > > WDYT? > > > > > > > > > > [3340] https://github.com/apache/polaris/pull/3340 > > > > > > > > > > Thanks, > > > > > Dmitri. > > > > > > > > > > On Tue, Dec 30, 2025 at 6:12 PM Yufei Gu <[email protected]> > > wrote: > > > > > > > > > > > Hi folks, > > > > > > > > > > > > I would like to start a discussion on simplifying modules > > > polaris-admin > > > > > > into polaris-server. The separate admin module has been a > recurring > > > > source > > > > > > of friction. It effectively doubles license checks, Docker image > > > > > > publishing, and binary publishing(almost double the size of the > > > binary > > > > > > distribution due to most libs being shared), and it also forces > > > > additional > > > > > > shared modules like common, test-common, and distribution(there > is > > no > > > > need > > > > > > to have a separate distribution module if there is only one > > > quarkus-run > > > > > > jar). Over time this has increased build, release, and > maintenance > > > > > > complexity with minor benefits. > > > > > > > > > > > > One alternative worth considering is moving toward a single > runtime > > > > module > > > > > > that supports both server and administrative CLI operations. Many > > > > mature > > > > > > OSS projects follow this model successfully. For example, Apache > > > Spark > > > > > > ships a single set of core artifacts, and multiple CLI tools such > > as > > > > spark > > > > > > submit, spark shell, and spark sql are essentially thin wrappers > > that > > > > point > > > > > > to the same underlying jars. This keeps the distribution simple > > while > > > > still > > > > > > allowing clear separation between interactive, batch, and > > > > administrative > > > > > > workflows. > > > > > > > > > > > > Here are the initial discussions, > > > > > > > https://github.com/apache/polaris/pull/3281#discussion_r2652055703 > > . > > > > Thanks > > > > > > Dmitri for the detailed explanation and discussion. > > > > > > > > > > > > Here is a POC(https://github.com/apache/polaris/pull/3340), > which > > > > verified > > > > > > that both model works in a single jar: > > > > > > Server Mode: > > > > > > java -jar runtime/server/build/quarkus-app/quarkus-run.jar > > > > > > > > > > > > CLI Mode: > > > > > > java -jar runtime/server/build/quarkus-app/quarkus-run.jar > --help > > > > > > java -jar runtime/server/build/quarkus-app/quarkus-run.jar > > > bootstrap > > > > > > --help > > > > > > > > > > > > Thanks, > > > > > > Yufei > > > > > > > > > > > > > > > >
