Hi Yufei,

Refreshing this discussion a bit.

To recap my overall thinking:

I believe merging the Admin Tool and the Server in terms of distribution
artifacts is a good idea. As you noted it will simplify license management
and the binary distribution. However, LICENSE changes in [3340] seem to
require additional review and adjustments as Robert noted.

In terms of source module layout, as I commented in [3340], I believe it is
still worth keeping the `runtime/admin` directory in the source tree, build
a jar from it, but not a Quarkus application. Then the jar will be included
into the Quarkus build under `runtime/server`.

The dir name `runtime/admin` might not be true to the "runtime" claim after
this refactoring, but I guess we can rename it (while still keeping it as
a separate source module) after it gets integrated into the server. This is
just to reduce the PR complexity.

WDYT?

[3340] https://github.com/apache/polaris/pull/3340

Thanks,
Dmitri.

On Tue, Dec 30, 2025 at 6:12 PM 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
>

Reply via email to