Hi Yufei, I am not aware of how the Admin CLI code is reused right now.
My question to you was about what you think about keeping this reuse option open to Polaris users :) Why the server module cannot be reused is briefly described in [1]. Specific issues are pretty convoluted. If you're interested in delving deep into them, it would probably be best to do that in a dedicated thread. [1] https://polaris.apache.org/in-dev/unreleased/downstream-build/ Cheers, Dmitri. On Fri, Feb 20, 2026 at 2:07 PM Yufei Gu <[email protected]> wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > >
