Rather than silencing the whole class, I'd suggest modifying the maybeBootstrap method as follows:

  public void maybeBootstrap(
      @Observes Startup event,
      MetaStoreManagerFactory factory,
      PersistenceConfiguration config,
      RealmContextConfiguration realmContextConfiguration) {

    if (ConfigUtils.isProfileActive("cli")) {
      return; // never bootstrap realms in CLI profile
    }
...

I'd also suggest moving this method to a separate class, as it is becoming quite big and complex.

SGTM. Adopted the change.

For moving it to a separate class, I'd suggest to tackle it in a followup PR given the current PR is big already.

How is it possible to invoke the Admin CLI without a subcommand now? 🤔

Both work per my test. I have removed the comment to avoid confusion.

yufei@Yufeis-MacBook-Pro-2 polaris % java -jar runtime/server/build/quarkus-app/quarkus-run.jar -h
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@Yufeis-MacBook-Pro-2 polaris % java -jar runtime/server/build/quarkus-app/quarkus-run.jar purge -h
Usage: polaris-admin-tool.jar purge [-hV] -r=<realm> [-r=<realm>]...
Purge realms and all associated entities.
  -h, --help            Show this help message and exit.
  -r, --realm=<realm>   The name of a realm to purge.
  -V, --version         Print version information and exit.

Is this necessary? I suppose runtime/server included polaris-core before 🤔

Changed it to compileOnly, otherwise the compilation will fail.

Oh, I did not mean to imply that the dep. was wrong... I was just wondering 🙂

If core is require for complication, we should probably keep it as an implementation dep.

Let's try to find a more natural way to perform readiness checks under the CLI env.

Sure, I'm open for suggestions.

It's safer to use the following idiom, as more than one profile can be specified with quarkus.profile:

if (ConfigUtils.isProfileActive("cli")) {

Fixed in the new commit. Thanks for the suggestion.

I believe we simply need to remove Quarkus Admin Tests here, not rename

Removed, however, the CI is still asking for it as a pending task. Maybe we should remove it first in a separate PR?

Filed #3370 to unblock this PR.

Should we suppress CONSOLE log instead but keep default levels informative in case a user enabled FILE logging?

I'm open for that, but the WARN level logging was carried from the application.properties in the removed admin module,

ah, sorry, I missed that. Current code is fine for now 👍

for follow-up: with a single binary package, we may want to rename / restructure the binary dist for clarity.

Definitely, there are a few places needed to be changed, including doc. I will address them in followups.

This is probably ok in the interest of progress, but in general I hope we could leverage profile-specific config like polaris.production.readiness.checks.enabled=true (or false for CLI). WDYT?

That's probably a good idea, esp. if we want to group a set of methods under the same configure key, instead of spreed if (ConfigUtils.isProfileActive("cli") in multiple places. We could improve in followups.

I believe using dedicated config properties for this is a small change :) but I'm also ok with addressing this in a follow-up PR.

Same here: I'd prefer to use explicit config flags (set differently in each profile) vs. checking the name of the profile, please.

See #3340 (comment)

I believe using dedicated config properties for this is a small change :) but I'm also ok with addressing this in a follow-up PR.

Nice 👍

Agree with @dimas-b these should be implementation for most of them. I would reorder them as below:

    implementation(project(":polaris-core"))
    implementation(project(":polaris-version"))
    implementation(project(":polaris-api-management-service"))
    implementation(project(":polaris-api-iceberg-service"))
    implementation(project(":polaris-runtime-service"))

    compileOnly("com.fasterxml.jackson.core:jackson-annotations")

    implementation("io.quarkus:quarkus-picocli")

Fixed

As I mentioned on the ML, I'm unsure whether we should mention the possibility of adding this profile-aware external config file, as it has very little added value.

+1 Let's advise users to customize via the profile-neutral application.properties (and/or corresponding -D and env. vars).

If a user runs both the server and the CLI with the same Polaris binary of the same location, a shared application.properties applies to both use cases. In that setup, having a separate application-cli.properties still seems useful to capture CLI specific configuration that should not affect the server behavior. That separation feels reasonable and keeps the shared defaults clean while allowing targeted overrides for the CLI. For example, CLI specific configs like the following will be overwritten by application.properties

quarkus.banner.enabled=false
quarkus.log.level=WARN

WDYT?

AFAIK, profile-specific config works in conjunction with the profile-neutral config. In other words, application.properties is always loaded. This might be too much low-level details for end users to think about.

Even if all the code is bundled in the same Quarkus application, Server and Admin could still have distinct shell entry points and distinct application.properties files (each in its own directory). That would be my preference for the tar-based distribution.

Docker images can bundle anything that Polaris developers are ok with. In docker, users will override config via external mechanisms like env. variables. If a config map is used to define application.properties it will be specific to a particular runtime scenario anyway (Server or Admin, but not both).

profile-specific config works in conjunction with the profile-neutral config

That's true, and I can confirm that's how it work today.

This might be too much low-level details for end users to think about.

This isn't a user-face doc. This is a comment in the source code. I think it should be fine to be here to provide complete view of how it works.

Even if all the code is bundled in the same Quarkus application, Server and Admin could still have distinct shell entry points and distinct application.properties files (each in its own directory). That would be my preference for the tar-based distribution.
Docker images can bundle anything that Polaris developers are ok with. In docker, users will override config via external mechanisms like env. variables. If a config map is used to define application.properties it will be specific to a particular runtime scenario anyway (Server or Admin, but not both).

I understand that these particular use cases may not require profile specific config files today. That said, this does not mean the scenarios I mentioned will never occur. Providing clear and explicit messaging still has value in that context. Even if a user never actively uses External config/application-cli.properties as a profile specific external config, having a clear understanding of how it works can be important when diagnosing or debugging unexpected behavior.

Sorry for the last minute comment here, but I wonder if it might make sense to keep the runtime/admin module as a home for Admin code, but not build a Quarkus app from it. The runtime/server module will then import runtime/admin and we end up with one Quarkus app both for the Server and Admin Tool... WDYT?

My rationale for keeping the runtime/admin module is just better code isolation at compile time. The runtime/server module is mostly an assembly descriptor, ATM it does not have any feature code. It might be preferable to keep it this way to allow simpler reuse of feature code from their dedicated modules.

+1, that's actually a nice idea!

I see the appeal of this approach, but I worry it may dismiss some of the key benefits of the current refactor(we will need a few common modules to enable a separate admin module), and make the dependency structure less clearer. Please note that, the CLI will need ServiceProvider to work now.
It also makes testing a bit awkward. Tests that are specific to the CLI behavior would have to depend on the default and service module just to pick up application-cli and application properties , which feels indirect and less explicit. For those reasons, I think the current direction still has advantages in terms of modularity, clarity, and test ergonomics.

I agree on "test ergonomics" as an advantage in the current diff of this PR, but I do not think "modularity" is better - that's exactly what I meant to highlight in my comment above :)

IMHO, better modularity is preferable to "test ergonomics".

Testing the admin tool could follow the same approach as testing OPA (which is not monolithic with the server, but a pure puglin)... WDYT?

We will need a few common modules to enable a separate admin module. I believe this is one of areas we used to struggle with.

In terms of modularity, splitting functionalities across multiple modules does not automatically improve modularity. In many cases it does the opposite. It makes the dependency graph harder to reason about, and forces consumers and tests to pull in modules that exist only to host a thin slice of logic. I think good modularity is about cohesion and clear ownership. A module should group functionality that changes together and represents a meaningful boundary. And I'm not a fan of how we layout OPA modules.

In practice, over splitting often trades real modularity for superficial structure, while introducing costs in test ergonomics, dependency clarity, and mental overhead. Keeping related behavior together, even if it is small, is often the more modular choice. I have mentioned that we have to keep introducing new modules like runtime/common, runtime/test-common, runtime/distribution, they are the side effect of over splitting, which can be avoided in the beginning.

I don't think keeping the admin module around is "over-splitting".

This PR, while interesting in that it achieves a single artifact/jar for both usages (server and CLI), does create an imbalanced layout where the top module includes code for the CLI, but the code for the server lives in a dependency:

flowchart TD
    A["`polaris-server<br/>(incl. admin tool)`"] --> B
    B[polaris-runtime-service]

Whereas @dimas-b proposal still keeps the single entrypoint but each usage has its own module:

flowchart TD
    A[polaris-server] --> B
    A --> C
    B[polaris-runtime-service] --> D
    C[polaris-admin] --> E
    B --> F
    C --> F
    D[specific deps]
    E[specific deps]
    F[common deps]

This has a net advantage imho of leaving polaris-server as a mere "assembly descriptor" as @dimas-b puts it.

It makes the dependency graph harder to reason about, and forces consumers and tests to pull in modules that exist only to host a thin slice of logic

I don't buy much this argument: while a proliferation of modules can complicate the dependency graph, modularity offers many upsides: modern build tools efficiently manage even hundreds of dependencies; a DAG enforces clearer mental models about dependencies than monoliths that often create dependency cycles; smaller modules accelerate compilation; and downstream integrators benefit from leaner CDI contexts.

Polaris is currently in an intermediate, non-optimal state: it's neither a monolith, nor a well organized modular application. We should rethink the purpose of those "common" modules, but also consider separating disparate concerns in modules like polaris-runtime-service: what does telemetry have to do with authentication? And what does the secrets manager have to do with events processing? I support moving towards a well-thought modular organization, and I think @dimas-b suggestion goes in that direction.

@flyrain : WDYT about this proposal?

Unrelated change to this already big PR.

Noop change in this big PR.

This should not be removed from the bom

This file has been moved, not removed.

Good point. We should just update the path (and possibly move this line if sort order matters).

The LICENSE file contains entries that are not migrated.