Hi Alex, Thanks a lot for taking the extra step to confirm this with the Quarkus community.
I agree we should be careful to keep the cli profile free of any build time configuration, I have added the WARN message in the file "application-cli.properties", check the latest commit[1] for details. I also like the suggestion of adding @QuarkusMainIntegrationTest coverage to exercise the final jar, let me know what extra coverage we could add. I have updated the PR[1], which clarifies the configuration priority order in class "PolarisApplication". We can add it to the doc in followup PRs. * <ol> * <li>(400) System properties: -D flags at JVM startup * <li>(300) Environment variables * <li>(260) External config/application-cli.properties: Profile-specific external config * <li>(260) External config/application.properties: Base external config * <li>(250) Classpath application-cli.properties: Profile-specific bundled config * <li>(250) Classpath application.properties: Base bundled config * </ol> Thanks again for the detailed feedback and validation. 1. https://github.com/apache/polaris/pull/3340 Yufei On Wed, Jan 7, 2026 at 1:45 AM Alexandre Dutra <[email protected]> wrote: > 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 > > > > >> > > > > > >> > > > > > > > > > > > > >
