Hi all, >From my perspective, there are two distinct discussions here:
1. Where the Polaris Console lives: I still believe it should stay in polaris-tools for now. This aligns with how we handle other clients, and to some extent, components like Spark could eventually reside in the polaris-tools repository as well. 2. Where the Polaris Console is packaged: Here, we can discuss the trade-offs between an external/sidecar console and packaging the console directly as part of the Polaris server. In the short term (which is step one from my previous email), I think we should focus on the standalone Polaris Console release, while keeping it in the polaris-tools repository. However, I understand Robert's point about revisiting the packaging options as we move forward. Regards, JB On Thu, Jul 30, 2026 at 12:18 AM Yufei Gu <[email protected]> wrote: > > Thanks for revisiting this discussion. > > I'm trying to understand why PR #260 changes the architectural conclusion. > My understanding is that the Console is still fundamentally a REST client. > Supporting an additional authentication flow for a different deployment > model changes the client implementation, but I'm not sure it changes the > overall architecture. > > In particular, I'm not yet seeing why adding proxy authentication means the > Console should now be served from polaris-server or why Quarkus should own > the authentication logic. Many standalone web clients support multiple > authentication mechanisms while remaining independently deployable. > > Could you elaborate on what specific architectural or security concern PR > #260 introduces that cannot be addressed while keeping the Console as a > separate client? Is the concern duplicated authentication logic, a > particular security risk, operational complexity, or something else? > > Besides, I also wanted to bring up a point from the previous discussion. > One of the arguments[1] against moving client side components into the main > Polaris repository was the additional LICENSE/NOTICE overhead and, more > importantly, maintaining a clear separation of concerns. If the Console is > still an independently deployed REST client, the same reasoning still > applies. > > However, it feels like we've been deciding whether a tool belongs in the > main Polaris repository on a case-by-case basis. I'd be supportive of > defining a clearer set of principles so future tools can be evaluated > consistently. For example, we could consider questions such as whether a > component interacts with Polaris purely through the public REST APIs, or > whether there is a strong downstream need for it to ship together with the > Polaris server. These are just examples, more thoughts are welcome if we > want to go that direction. In general, having explicit criteria like these > would make the decisions more consistent than evaluating each tool > independently. > > Understanding why PR #260 changes the answer under those criteria would > help me better understand why it's worth revisiting the previous conclusion. > > 1. https://lists.apache.org/thread/539p26bwk7zh1p4d1jqyhh2pqkkh0n36 > > Thanks, > > Yufei > > On Wed, Jul 29, 2026 at 6:33 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi > > > > Thanks Robert for updating this thread. > > > > It was also my first preference but I was to open to others proposals. > > I agree that things changed and we can revisit. > > > > I will come with a proposal to have console as part of Polaris-server > > (maybe in two steps). > > > > Thanks! > > > > Regards > > JB > > > > Le mer. 29 juil. 2026 à 13:00, Robert Stupp <[email protected]> a écrit : > > > > > Hi all, > > > > > > I'd like to revive this discussion because the proxy-authentication work > > in > > > `polaris-tools` PR #260 makes the server-integration question more > > > concrete. > > > > > > In June I was fine with keeping the first Console release in > > > `polaris-tools`, but explicitly left the main-repository and > > > server-bundling question open. > > > > > > The Console already implements a browser-side PKCE flow. > > > PR #260 now starts adding a second, proxy-specific model for user > > > information, session failures, logout, and reauthentication. > > > I think that is too much security-sensitive behavior for a mostly static > > > UI. > > > > > > My preference is to serve the static Console assets from `polaris-server` > > > and let Quarkus own the browser-facing OAuth/OIDC flow and session. > > > The Console would then only consume the authenticated identity and APIs. > > > > > > This is independent of whether the Console is enabled or exposed by > > > default. > > > Could we revisit that architecture now? > > > > > > Cheers, > > > Robert > > > > > > [260] https://github.com/apache/polaris-tools/pull/260 > > > > > > > > > On Wed, Jun 3, 2026 at 9:37 AM Robert Stupp <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > I am fine with keeping the first Console release in polaris-tools if > > that > > > > helps move the release forward. > > > > > > > > I just like to avoid treating this as a conclusion on the broader > > > > repository/artifact question. > > > > To me, "the Console is a REST client" is a useful deployment > > observation, > > > > but not a deciding argument for repository location or future artifact > > > > shape. > > > > > > > > So from my side, polaris-tools for the first release sounds fine as a > > > > pragmatic step. > > > > However, I expect the main-repo/server-bundling question to remain open > > > > for a follow-up discussion after that initial release. > > > > > > > > For that follow-up, I think we should come back to JB's original goals: > > > > * Improving Console visibility > > > > * Making contributions easier > > > > * Keeping releases aligned with Polaris API changes > > > > * Ensuring docs and deployment examples stay in sync with the server > > > > > > > > Robert > > > > > > > > On Tue, Jun 2, 2026 at 7:10 PM Jean-Baptiste Onofré <[email protected]> > > > > wrote: > > > > > > > >> Hi > > > >> > > > >> I agree with the isolation. However the original discussion focused > > more > > > >> on > > > >> contributions and visibility, not technical/packaging isolation. > > > >> > > > >> I also think that the website can give more space to the "clients" ( > > > >> https://polaris.apache.org/tools/ can be emphasized). > > > >> Also, a composable docker/sidecar documenting how to enable the > > console > > > >> should probably give more visibility. > > > >> > > > >> So, here's my consensus proposal: > > > >> 1. For now, let's keep the console in the polaris-tools repo > > > >> 2. Move forward quickly on a first release and update our > > > >> documentation/docker-compose to easily give users the option to enable > > > the > > > >> console > > > >> 3. Give more space to "clients" on the website > > > >> > > > >> I will work on these items. > > > >> > > > >> Regards > > > >> JB > > > >> > > > >> On Tue, Jun 2, 2026 at 7:02 PM Yufei Gu <[email protected]> wrote: > > > >> > > > >> > Given this discussion [1], I don't think putting the UI in the > > server > > > >> image > > > >> > makes sense at this point. We could revisit that decision in the > > > future > > > >> if > > > >> > the Console evolves into a multi tenant web application. > > > >> > > > > >> > If we continue to treat the Console as a separately deployed REST > > > >> client, > > > >> > I'm not convinced there is a strong reason to move it into the main > > > >> repo. > > > >> > This seems consistent with the position taken in the earlier MCP > > > >> discussion > > > >> > [2][3]: > > > >> > > > > >> > If MCP server goes in polaris main repo, than other tools could be > > > >> > > there too (console, catalog migrator, etc). But I don't think > > it's a > > > >> > > good idea due to the LICENSE/NOTICE overhead and also clear > > > separation > > > >> > > of concerns. > > > >> > > > > >> > > > > >> > I think the MCP server is a "client" for the Polaris server, like > > the > > > >> > > CLI or the Console (UI). > > > >> > > So, maybe it's worth considering polaris-tools as a host (it's > > what > > > >> > > I'm doing to the Polaris Console). > > > >> > > > > >> > > > > >> > To me, the same reasoning still applies. If the Console remains an > > > >> > independent client that interacts with Polaris exclusively through > > > REST > > > >> > APIs, keeping it separate preserves a clear separation of concerns > > and > > > >> > allows it to evolve independently. Moving it into the main repo > > would > > > >> > therefore require a stronger justification. > > > >> > > > > >> > 1. https://lists.apache.org/thread/v4jqvfdw0myxkgfzb01t2787nz7oyzbw > > > >> > 2. https://lists.apache.org/thread/539p26bwk7zh1p4d1jqyhh2pqkkh0n36 > > > >> > 3. https://lists.apache.org/thread/yj98vol73dhpvygmyxm23sgjbnf7zfsd > > > >> > > > > >> > Yufei > > > >> > > > > >> > > > > >> > On Tue, Jun 2, 2026 at 7:59 AM Dmitri Bourlatchkov < > > [email protected]> > > > >> > wrote: > > > >> > > > > >> > > Hi JB, > > > >> > > > > > >> > > This plan sounds good to me. > > > >> > > > > > >> > > While packaging the UI in the same image as the server may help > > > fresh > > > >> > > users, keeping a separate UI image will likely have less impact on > > > >> > existing > > > >> > > deployments. Docker compose profiles seem like a good middle > > ground > > > >> from > > > >> > > the UX perspective. > > > >> > > > > > >> > > Cheers, > > > >> > > Dmitri. > > > >> > > > > > >> > > On Tue, Jun 2, 2026 at 7:22 AM Jean-Baptiste Onofré < > > > [email protected]> > > > >> > > wrote: > > > >> > > > > > >> > > > Hi, > > > >> > > > > > > >> > > > To provide some perspective based on my experience with other > > > Apache > > > >> > > > projects that include a UI by default (such as ActiveMQ, NiFi, > > > >> Druid, > > > >> > and > > > >> > > > Hop), I don't believe the console necessarily needs to be > > enabled > > > by > > > >> > > > default. While a seamless out-of-the-box user experience is key > > > for > > > >> > > getting > > > >> > > > started quickly with Polaris, we must also recognize that > > console > > > >> > > > requirements vary depending on the deployment. > > > >> > > > > > > >> > > > I propose keeping the Polaris server distribution and Docker > > image > > > >> > > focused > > > >> > > > solely on the server as they are today. We can then offer the > > > >> console > > > >> > > (and > > > >> > > > potentially other REST clients) as a sidecar or composable > > > >> container. > > > >> > > Using > > > >> > > > Docker Compose profiles, we could structure it like this: > > > >> > > > > > > >> > > > services: > > > >> > > > console: > > > >> > > > image: polaris-console... > > > >> > > > profiles: [console] > > > >> > > > server: > > > >> > > > image: polaris-server... > > > >> > > > > > > >> > > > Users could then simply run docker compose --profile console up > > to > > > >> > > include > > > >> > > > the UI. > > > >> > > > > > > >> > > > In summary, I propose: > > > >> > > > > > > >> > > > 1. Moving the console code to a module within the main > > repository > > > >> to > > > >> > > > improve visibility and contributions. > > > >> > > > 2. Providing a Docker Compose setup with profiles and updating > > > the > > > >> > Helm > > > >> > > > chart to include the console as an optional component. > > > >> > > > > > > >> > > > Thoughts? > > > >> > > > > > > >> > > > Regards, > > > >> > > > JB > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > On Tue, Jun 2, 2026 at 3:21 AM Yufei Gu <[email protected]> > > > >> wrote: > > > >> > > > > > > >> > > > > I think the Console is essentially a REST client, so I’m not > > > sure > > > >> it > > > >> > > > should > > > >> > > > > belong to the server Docker image by default. > > > >> > > > > > > > >> > > > > Could we publish it as a separate client artifact instead, for > > > >> > example > > > >> > > to > > > >> > > > > PyPI or a similar distribution channel, depending on the > > > >> > > implementation? > > > >> > > > > That would keep the server image focused on serving the API, > > > while > > > >> > > still > > > >> > > > > making the Console easy to install, release, and consume. > > > >> > > > > > > > >> > > > > We can still keep it in the main repo, but I didn't see much > > > >> benefit > > > >> > of > > > >> > > > > doing so when we treat it as a separate deployable component. > > > >> > > > > > > > >> > > > > Yufei > > > >> > > > > > > > >> > > > > > > > >> > > > > On Mon, Jun 1, 2026 at 12:02 PM Romain Manni-Bucau < > > > >> > > > [email protected]> > > > >> > > > > wrote: > > > >> > > > > > > > >> > > > > > I like the on by default in docker, off by default in helm > > > >> > > compromise - > > > >> > > > > > that said it still makes sense to split it for prod if > > desired > > > >> > cause > > > >> > > it > > > >> > > > > > will not use the same service/httproute at all IMHO, one > > will > > > be > > > >> > > public > > > >> > > > > > like versus the other can stay internal most of the time. > > > >> > > > > > > > > >> > > > > > Romain Manni-Bucau > > > >> > > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > >> > > > > > <https://dotnetbirdie.github.io/> | Blog < > > > >> > > > https://rmannibucau.github.io/ > > > >> > > > > > > > > >> > > > > > | Old > > > >> > > > > > Blog <http://rmannibucau.wordpress.com> | Github > > > >> > > > > > <https://github.com/rmannibucau> | LinkedIn > > > >> > > > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > >> > > > > > < > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > >> > > > > > > > > > >> > > > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > Le lun. 1 juin 2026 à 20:14, Yong Zheng < > > > >> [email protected]> > > > >> > a > > > >> > > > > écrit > > > >> > > > > > : > > > >> > > > > > > > > >> > > > > > > Hello, > > > >> > > > > > > > > > >> > > > > > > Why not put them in the same repo but keep them separate > > > >> (similar > > > >> > > to > > > >> > > > > > spark > > > >> > > > > > > plugin which doesn’t get include automatically). Same > > apply > > > to > > > >> > helm > > > >> > > > as > > > >> > > > > > > people can decide on what to deploy and avoid UI component > > > if > > > >> > > > desired. > > > >> > > > > > > > > > >> > > > > > > As the UI is SPA, the actually calls are from client > > browser > > > >> as > > > >> > > > opposed > > > >> > > > > > to > > > >> > > > > > > UI pod, the usability may be limited there in certain use > > > >> cases. > > > >> > I > > > >> > > > > would > > > >> > > > > > > start a different ML for this topic. > > > >> > > > > > > > > > >> > > > > > > Thanks, > > > >> > > > > > > Yong Zheng > > > >> > > > > > > > > > >> > > > > > > > On Jun 1, 2026, at 11:52 AM, Dmitri Bourlatchkov < > > > >> > > [email protected] > > > >> > > > > > > > >> > > > > > > wrote: > > > >> > > > > > > > > > > >> > > > > > > > Hi All, > > > >> > > > > > > > > > > >> > > > > > > > The idea of moving the UI to the main repo SGTM. > > > >> > > > > > > > > > > >> > > > > > > > I tend to agree with Romain, that the UI should be easy > > to > > > >> > > > _disable_ > > > >> > > > > > > > because in production environments it may not be > > intended > > > to > > > >> > run > > > >> > > at > > > >> > > > > > all, > > > >> > > > > > > or > > > >> > > > > > > > perhaps not on the same nodes as the main Polaris > > server. > > > >> The > > > >> > > > > > simplicity > > > >> > > > > > > of > > > >> > > > > > > > the UI (static pages + REST API via JS) may not justify > > > >> always > > > >> > > > > running > > > >> > > > > > it > > > >> > > > > > > > from the SRE perspective, I guess. > > > >> > > > > > > > > > > >> > > > > > > > I'm sure there are multiple ways to tackle this in helm. > > > >> For a > > > >> > > > > start, a > > > >> > > > > > > > simple on/off helm value might be sufficient, though. > > > >> > > > > > > > > > > >> > > > > > > > Regarding defaults, how about ON by default in plain > > > docker > > > >> > (for > > > >> > > > > local > > > >> > > > > > > > runs), but OFF by default in helm (mostly for "prod" > > > >> > > environments)? > > > >> > > > > > > > > > > >> > > > > > > > Cheers, > > > >> > > > > > > > Dmitri. > > > >> > > > > > > > > > > >> > > > > > > >> On Mon, Jun 1, 2026 at 11:44 AM Romain Manni-Bucau < > > > >> > > > > > > [email protected]> > > > >> > > > > > > >> wrote: > > > >> > > > > > > >> > > > >> > > > > > > >>> Le lun. 1 juin 2026 à 17:35, Robert Stupp < > > > [email protected]> > > > >> a > > > >> > > > > écrit : > > > >> > > > > > > >>> > > > >> > > > > > > >>> But isn't the concern solved with the configuration > > > option > > > >> > > > "enable > > > >> > > > > > web > > > >> > > > > > > >> UI = > > > >> > > > > > > >>> true|false"? > > > >> > > > > > > >>> > > > >> > > > > > > >> > > > >> > > > > > > >> if default is false it does but breaks the easy by > > > default > > > >> no? > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >>> > > > >> > > > > > > >>> With a standalone web UI, as it exists today, > > everybody > > > >> can > > > >> > run > > > >> > > > it > > > >> > > > > > and > > > >> > > > > > > >>> perform "click-ops." > > > >> > > > > > > >>> Similar for custom built web UIs. > > > >> > > > > > > >>> Or if some user extracts the static files and serves > > > their > > > >> > own > > > >> > > > > > instance > > > >> > > > > > > >>> using a local http daemon. > > > >> > > > > > > >>> > > > >> > > > > > > >>> The web UI doesn't allow anything that cannot be done > > > via > > > >> > > another > > > >> > > > > > > >>> interface, such as a terminal and `curl`. > > > >> > > > > > > >>> > > > >> > > > > > > >> > > > >> > > > > > > >> yes but it is less tempting enough to be sufficient for > > > me > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >>> > > > >> > > > > > > >>> With that, I'm not sure maintaining multiple different > > > >> > > > > distributions > > > >> > > > > > > >> really > > > >> > > > > > > >>> helps lock people out of web UIs ("click-ops"). > > > >> > > > > > > >>> > > > >> > > > > > > >> > > > >> > > > > > > >> from my windows integrating the ui is not helping since > > > you > > > >> > need > > > >> > > > the > > > >> > > > > > > >> database anyway so maybe the ui outside is sufficient > > too > > > >> else > > > >> > > the > > > >> > > > > all > > > >> > > > > > > in > > > >> > > > > > > >> one with h2 or pg will help, i'm not clear on it > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >>> > > > >> > > > > > > >>> Robert > > > >> > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > > >>> On Mon, Jun 1, 2026 at 5:15 PM Romain Manni-Bucau < > > > >> > > > > > > [email protected] > > > >> > > > > > > >>> > > > >> > > > > > > >>> wrote: > > > >> > > > > > > >>> > > > >> > > > > > > >>>> Le lun. 1 juin 2026 à 17:12, Robert Stupp < > > > >> [email protected]> > > > >> > a > > > >> > > > > écrit > > > >> > > > > > : > > > >> > > > > > > >>>> > > > >> > > > > > > >>>>> Hi Romain, > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>> Disabling the console (web UI) is easy once it > > becomes > > > >> part > > > >> > > of > > > >> > > > > the > > > >> > > > > > > >>>>> polaris-server. > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>> To clarify, the web UI is a static web resource, it > > > >> doesn't > > > >> > > > > execute > > > >> > > > > > > >>>> web-UI > > > >> > > > > > > >>>>> code in Quarkus. > > > >> > > > > > > >>>>> The UI uses the same authentication and > > authorization > > > >> > > > mechanisms > > > >> > > > > > that > > > >> > > > > > > >>> any > > > >> > > > > > > >>>>> REST client uses; it is just a UI on top of that. > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>> > > > >> > > > > > > >>>> > > > >> > > > > > > >>>> Yep, this is my issue, it is trivial to use and break > > > the > > > >> > "all > > > >> > > > as > > > >> > > > > > > code" > > > >> > > > > > > >>>> pattern and get back to click-ops pattern. > > > >> > > > > > > >>>> Being API only is less tempting so I'm trying to > > stick > > > to > > > >> > > that. > > > >> > > > > > > >>>> > > > >> > > > > > > >>>> *Still thinking out loud* but having 3 images sounds > > > the > > > >> > best > > > >> > > of > > > >> > > > > all > > > >> > > > > > > >>>> worlds: > > > >> > > > > > > >>>> > > > >> > > > > > > >>>> * server > > > >> > > > > > > >>>> * frontend/ui > > > >> > > > > > > >>>> * all-in-one (== demo) > > > >> > > > > > > >>>> > > > >> > > > > > > >>>> It is the pattern used by most products (all in one > > can > > > >> even > > > >> > > > embed > > > >> > > > > > > >>> postgres > > > >> > > > > > > >>>> to really be ready to use) and everybody will be > > happy > > > >> at a > > > >> > > very > > > >> > > > > low > > > >> > > > > > > >> cost > > > >> > > > > > > >>>> in terms of dev/maintenance and infra IMHO. > > > >> > > > > > > >>>> > > > >> > > > > > > >>>> Hope it makes sense. > > > >> > > > > > > >>>> > > > >> > > > > > > >>>> > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>> Hope this helps, > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>> Robert > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>> On Mon, Jun 1, 2026 at 4:33 PM Romain Manni-Bucau < > > > >> > > > > > > >>> [email protected] > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>> wrote: > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>>>> Hi, > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> as an user I have a small request: can it be > > disabled > > > >> by > > > >> > > > default > > > >> > > > > > > >> (or > > > >> > > > > > > >>>> made > > > >> > > > > > > >>>>>> unusable by disabling the authn) or at least be > > made > > > >> easy > > > >> > to > > > >> > > > > > > >> disable > > > >> > > > > > > >>>>>> (corrollar being: can we get a headless docker > > image, > > > >> > solves > > > >> > > > my > > > >> > > > > > > >>> concern > > > >> > > > > > > >>>>>> too)? > > > >> > > > > > > >>>>>> rational is that when you have everything automated > > > >> around > > > >> > > > > polaris > > > >> > > > > > > >>> you > > > >> > > > > > > >>>>>> don't want the UI to be able to mess up things nor > > > >> render > > > >> > a > > > >> > > > > > > >> different > > > >> > > > > > > >>>>> view. > > > >> > > > > > > >>>>>> not my usage but an in between readonly enforced > > > mode - > > > >> > even > > > >> > > > for > > > >> > > > > > > >>> admin > > > >> > > > > > > >>>>>> users - can be useful I think so maybe 3 modes in > > > >> terms of > > > >> > > > > toggle: > > > >> > > > > > > >>>> Full, > > > >> > > > > > > >>>>>> ReadOnly, Off or alike. > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> Shouldn't be crazy to do with quarkus but think it > > is > > > >> an > > > >> > > > > important > > > >> > > > > > > >>>>> feature > > > >> > > > > > > >>>>>> to integrate it cleanly as a global solution. > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> the tricky part is to make the prod and dev > > defaults > > > >> > > > converging > > > >> > > > > > but > > > >> > > > > > > >>>>> quarkus > > > >> > > > > > > >>>>>> has a profile option by default which can be the > > way > > > to > > > >> > > solve > > > >> > > > > it. > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> hope it makes sense. > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> Romain Manni-Bucau > > > >> > > > > > > >>>>>> @rmannibucau <https://x.com/rmannibucau> | .NET > > Blog > > > >> > > > > > > >>>>>> <https://dotnetbirdie.github.io/> | Blog < > > > >> > > > > > > >>>> https://rmannibucau.github.io/ > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> | Old > > > >> > > > > > > >>>>>> Blog <http://rmannibucau.wordpress.com> | Github > > > >> > > > > > > >>>>>> <https://github.com/rmannibucau> | LinkedIn > > > >> > > > > > > >>>>>> <https://www.linkedin.com/in/rmannibucau> | Book > > > >> > > > > > > >>>>>> < > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>> > > > >> > > > > > > >>> > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > >> > > > > > > >>>>>>> > > > >> > > > > > > >>>>>> Javaccino founder (Java/.NET service - contact via > > > >> > linkedin) > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>> Le lun. 1 juin 2026 à 15:28, Jean-Baptiste Onofré < > > > >> > > > > > [email protected] > > > >> > > > > > > >>> > > > >> > > > > > > >>> a > > > >> > > > > > > >>>>>> écrit : > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>>> Hi, > > > >> > > > > > > >>>>>>> > > > >> > > > > > > >>>>>>> Yes, that is indeed part of the proposal. > > > >> > > > > > > >>>>>>> > > > >> > > > > > > >>>>>>> The goal is to provide the UI as soon as the > > Polaris > > > >> > server > > > >> > > > > > > >> starts > > > >> > > > > > > >>> to > > > >> > > > > > > >>>>>>> ensure a better experience for our users. > > > >> > > > > > > >>>>>>> > > > >> > > > > > > >>>>>>> Regards, > > > >> > > > > > > >>>>>>> JB > > > >> > > > > > > >>>>>>> > > > >> > > > > > > >>>>>>> On Mon, Jun 1, 2026 at 3:12 PM Robert Stupp < > > > >> > > [email protected]> > > > >> > > > > > > >>> wrote: > > > >> > > > > > > >>>>>>>> > > > >> > > > > > > >>>>>>>> +1 > > > >> > > > > > > >>>>>>>> > > > >> > > > > > > >>>>>>>> Could we then bundle the Console with the Polaris > > > >> > server? > > > >> > > > > > > >>>>>>>> > > > >> > > > > > > >>>>>>>> On Mon, Jun 1, 2026 at 8:01 AM Jean-Baptiste > > > Onofré < > > > >> > > > > > > >>>> [email protected] > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>>>> wrote: > > > >> > > > > > > >>>>>>>> > > > >> > > > > > > >>>>>>>>> Hi everyone, > > > >> > > > > > > >>>>>>>>> > > > >> > > > > > > >>>>>>>>> As mentioned on the dev mailing list a few days > > > >> ago, I > > > >> > am > > > >> > > > > > > >>>> currently > > > >> > > > > > > >>>>>>>>> preparing the first release of the Polaris > > > Console. > > > >> > There > > > >> > > > is > > > >> > > > > > > >>>>>>>>> significant interest in the Console, and it is a > > > key > > > >> > > > > > > >> component > > > >> > > > > > > >>> of > > > >> > > > > > > >>>>> our > > > >> > > > > > > >>>>>>>>> efforts to improve the onboarding experience. > > > >> > > > > > > >>>>>>>>> > > > >> > > > > > > >>>>>>>>> After discussing this with Yong, who started to > > > help > > > >> > with > > > >> > > > the > > > >> > > > > > > >>>>>> console, > > > >> > > > > > > >>>>>>>>> we believe that moving the Console into the main > > > >> > Polaris > > > >> > > > > > > >>>> repository > > > >> > > > > > > >>>>>>>>> would provide better visibility and encourage > > > >> further > > > >> > > > > > > >>>>> contributions. > > > >> > > > > > > >>>>>>>>> This would also allow it to be released as part > > of > > > >> the > > > >> > > main > > > >> > > > > > > >>>> Polaris > > > >> > > > > > > >>>>>>>>> release cycle. Additionally, the Console could > > be > > > >> > > included > > > >> > > > as > > > >> > > > > > > >>> an > > > >> > > > > > > >>>>>>>>> optional component in the main Helm chart, > > > allowing > > > >> > users > > > >> > > > to > > > >> > > > > > > >>>> choose > > > >> > > > > > > >>>>>>>>> whether to enable it. > > > >> > > > > > > >>>>>>>>> > > > >> > > > > > > >>>>>>>>> Thoughts? > > > >> > > > > > > >>>>>>>>> > > > >> > > > > > > >>>>>>>>> Regards, > > > >> > > > > > > >>>>>>>>> JB > > > >> > > > > > > >>>>>>>>> > > > >> > > > > > > >>>>>>> > > > >> > > > > > > >>>>>> > > > >> > > > > > > >>>>> > > > >> > > > > > > >>>> > > > >> > > > > > > >>> > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > >
