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