Hi Dmitri and JB, Thanks a lot to both of you for the thoughtful feedback and perspectives!
Dmitri, I agree that UX is not ideal, especially around logging and noisy warnings when users run a CLI command. I do think these are largely UX and wiring issues rather than fundamental blockers, and should be fixable with some work on execution modes, and startup behavior. I am happy to take this on and iterate on improving the UX there. JB, thanks as well for the strong support and the reminder to keep the admin side as lightweight as possible. I agree with the two step approach you suggested, first packaging together to reduce overall complexity, then simplify the admin tool. I will spend some time experimenting further and try to come back with improvements that address the CLI versus server UX concerns. Thanks again, Yufei On Wed, Dec 31, 2025 at 10:41 PM Jean-Baptiste Onofré <[email protected]> wrote: > Hi folks, > > I have advocated in the past that the admin tool (simple and Java-based, > not Python) should be integrated into the server as a convenient utility. > Therefore, I am 100% in agreement with this proposal. > > However, I believe the admin component should remain as light as possible, > as many users will likely use alternative clients to manage the server, > such as curl or the console. We could approach this in two steps: > 1. Package everything together. > 2. Simplify the admin dependencies to make it as lightweight as possible. > > Regards, > JB > > On Wed, Dec 31, 2025 at 12:12 AM 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 > > >
