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