I have to disagree here.
In this thread, we discuss that *Polaris ships as a binary bundle, not a
pre-built Kubernetes chart.*
That bundle includes both the server and the admin tool for a reason: it
guarantees version compatibility and gives every user a friction-free way
to bootstrap a catalog,
Polaris-server and the admin-tool are separate things. You deploy the
/server/ and let it run in k8s (or whatever). Bootstrapping via the
admin-tools happens rarely (once) and is rather performed from an
administrator's machine, whereas the server(s) run elsewhere. So server
and admin-tool are
Hi Yufei
Thanks for the PR (I left one comment in there).
About naming, I think we should use polaris-{version}-bin for clarity.
I will work on LICENSE, NOTICE, DISCLAIMER for this distribution as it
has to be "merged".
Regards
JB
On Wed, May 14, 2025 at 8:32 PM Yufei Gu wrote:
>
> Hi Folk,
>
Not at all. Thanks for the review, actually!
I think it's a good idea to name it polaris-bin-{version}.tgz or
polaris-{version}-bin.tgz, which indicates that it's a binary
distribution, not a source distribution. Let me make the change.
Yufei
On Wed, May 14, 2025 at 2:31 PM Dmitri Bourlatchkov
Thanks, Yufei! I added some comments in GH despite the "draft" PR status. I
hope you do not mind :)
Overall, using one distribution archive both for the server and the admin
tool makes sense to me.
4. Standardized the binary distribution package naming to
polaris-{version}.tgz and polaris-{ver
Hi Folk,
Thanks a lot for the discussion. Here is the PR(
https://github.com/apache/polaris/pull/1589) to merge the binary
distribution while still keeping module polaris-quarkus-admin and
polaris-quarkus-server separately.
*What’s included in the PR:*
1. Introduced a new module that combines
Other than duplicated downloads for shared jars, the big problem is that
the configuration difference between admin tool and server may cause server
issues, e.g., the admin tool may bootstrap a realm in a wrong database.
Let's move them into the same distribution package first. Then we can
conside
Thanks for the clarification, JB!
Packaging both the server and the admin tool in the same distribution
(archive) is certainly a good idea.
Cheers,
Dmitri.
On Tue, May 6, 2025 at 2:33 AM Jean-Baptiste Onofré wrote:
> Hi
>
> We can see two aspects here:
> - the merge of the applications
> - gat
Hi
We can see two aspects here:
- the merge of the applications
- gather applications in one package/distribution (tar.gz/zip)
I'm in favor of the later because:
- admin and server distributions share 80% of the same artifacts
- users have to download to "big" packages
We should keep the Quarkus
I guess this discussion is becoming bigger than just the merging of admin
and server modules.
I'd like to propose staying on the original narrow topic, so please share
concrete ideas about handling CLI and REST applications in the same module
under Quarkus. It may be possible, I never tried it per
*> Users already get two artfacts: one for the server, another for the
admin tool. Each one has a specific and distinct purpose. I personally do
not see a usability problem here.*
I definitely see a usability problem here. Consider that every command in
the CLI may have a distinct purpose but we sh
These applications are built by Quarkus using different plugins (CLI vs.
REST API).
The output of a module is normally one jar, hence only one main class.
If we were to add custom code to run both CLI and REST API from the same
jar, we'd be losing most of the benefits of Quarkus plugins that were
I don’t really understand the question. Are you asking how a single gradle
module can contain a CLI and a service? The naive way is just to have two
different main classes but perhaps you mean something else?
In Dropwizard this was seemingly the standard way of doing things, as you
could register
Hi Yufei,
Please note that the admin tool is a CLI application, while the quarkus
"server" is a REST application.
How do you envision supporting both CLI and REST API in the same module?
Thanks,
Dmitri.
On Mon, May 5, 2025 at 2:49 PM Yufei Gu wrote:
> Hi folks,
>
>
>
> I’d like to propose mer
Hi folks,
I’d like to propose merging the polaris-quarkus-admin and
polaris-quarkus-server modules. While modularization can bring benefits
like clearer separation of concerns, in this case, the split seems to cause
more friction than value. Here’s why I think merging makes sense:
1. Improve
15 matches
Mail list logo
