Thanks a lot for the review and all nice suggestions, Dmitri and Alex! 1. All regression tests and unit tests have passed now. 2. I have also moved out some optimization per suggestions to keep the PR smaller. 3. All comments are resolved.
Please take another look. Yufei On Mon, Jan 5, 2026 at 3:15 PM Dmitri Bourlatchkov < [email protected]> wrote: > Thanks, Yufei! > > I'll review it tomorrow. > > Cheers, > Dmitri. > > On Mon, Jan 5, 2026 at 6:04 PM Yufei Gu <[email protected]> wrote: > > > Hi Dmitri, some good news to share: made the change so that the CLI mode > > won't print out unrelated logs. This also makes configure simpler and > more > > consistent, as we don't need two different application.properties > files(one > > for server and one for admin tool) anymore. The current one in default > mode > > is good for both. I've also rebased it on your PR > > https://github.com/apache/polaris/pull/3341. > > > > Here is the test result from my local machine. > > yufei@Yufeis-MacBook-Pro-2 polaris % java -jar > > runtime/server/build/quarkus-app/quarkus-run.jar --help > > Usage: polaris-admin-tool.jar [-hV] [COMMAND] > > Polaris administration & maintenance tool > > -h, --help Show this help message and exit. > > -V, --version Print version information and exit. > > Commands: > > help Display help information about the specified command. > > bootstrap Bootstraps realms and root principal credentials. > > purge Purge realms and all associated entities. > > > > > > Yufei > > > > > > On Mon, Jan 5, 2026 at 10:10 AM Yufei Gu <[email protected]> wrote: > > > > > 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 > > >> > > > >> > > > > > >
