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