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 > > > > > > > > > > >
