Hi Yufei, Thanks for the warning in the application-cli.properties file, I think it is very clear now.
As for @QuarkusMainIntegrationTest, we can tackle that later, it's just a matter of adding some smoke tests for each command. Regarding the documentation though, I'm not convinced we need to mention the possibility of providing an external application-cli.properties file in user-facing docs. The cli profile exists solely to override some Polaris internal behaviors (change the app name and adjust some log levels, mostly), and is somewhat internal in that regard. Thus I believe that users can configure all of Polaris, both server and CLI, using just the "profile-agnostic" config sources. Therefore, an external application-cli.properties file, while valid, would not bring any benefit to users. Thanks, Alex On Wed, Jan 7, 2026 at 9:03 PM Yufei Gu <[email protected]> wrote: > > 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 > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > >
