Hi Yufei, I appreciate you tackling this, as it offers significant potential for simplification.
I was initially a bit reluctant because the proposed solution relies on a separate "cli" profile. So I went ahead and asked the Quarkus devs [1], and received confirmation that this approach is acceptable, with one critical caveat: the "cli" profile must not include any build-time options. If build-time options are present in the "cli" profile, tests might pass (because they use the "cli" profile), but the final jar will have been built under the "prod" profile and therefore may not function as expected. In conclusion, I am fully supportive of the idea, but we must exercise extreme caution regarding the configuration we place in the "cli" profile. One of the options we could explore to make sure the jar works is to introduce some tests annotated with `@QuarkusMainIntegrationTest` – as these exercise the final jar. Thanks, Alex [1]: https://quarkusio.zulipchat.com/#narrow/channel/187030-users/topic/General.20question.20on.20migration.20from.20Dropwizard.20to.20Quarkus/with/566666716 On Wed, Jan 7, 2026 at 2:24 AM Yufei Gu <[email protected]> wrote: > > 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 > > > >> > > > > >> > > > > > > > > >
