Having spent a while making the build much faster than it historically
was, if it was to go in the artemis repo directly I'd at least want a
way to disable building the console to allow keeping things more like
their current state, for all those times doing stuff not actually
involving the console (for me, thats actually most of the time).

Having it in its own repo does seem like it may be simpler and nicer
though, even if it comes with the 'do a console release first'
overhead when actually updating it. We dont do a huge number of
releases, and the console doesnt change for many of them, so I dont
think that should be too big an issue after some initial churn.

We can always change it if we dont like it, whichever route is chosen initially.

On Wed, 13 Mar 2024 at 11:26, Andy Taylor <andy.tayl...@gmail.com> wrote:
>
> The current Artemis console is based on HawtIO 1 which itself is written
> using Bootstrap. Bootstrap is old and no longer maintained so HawtIO (v3/4)
> has moved to use React and Patternfly and is also written in Typescript.
>
> I have been working in the background over the last several months to
> upgrade the console to hawtIO 4, this work can be found here
> <https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng>.
> This is still a WIP but is close to completion, I basically have to finish
> off some branding, fix the console tests and implement an upgrade feature.
> A couple of things to note:
>
>
>    - I have separated out the JMX tree and its tabs from the tabs that are
>    not related to the tree selection. I always found this a bit strange so now
>    there are 2 tabs Artemis and Artemis JMX, the latter uses the JMX tree as
>    before. It is possible however to do anything in the Artemis tab that you
>    can do in the JMX tab, view attributes and operations for instance. There
>    is an issue currently where if there are thousands of address or queues
>    then performance becomes an issue. this is because the whole JMX tree is
>    loaded into memory and this can cause even the broker to fall over. My plan
>    at some point is to allow disabling the JMX view and to lazy load in MBeans
>    as and when needed, this is a task for further down the road tho.
>    - The console is built using yarn and is incredibly slow to build, in
>    fact it takes longer than it takes to build the rest of Artemis. It may be
>    better to have the new console in its own repository, release it
>    independently and just consume it in Artemis. This means some extra work
>    for a release but once the console becomes stable it shouldn't be too much
>    work. I will however let the community decide what is the best approach.
>
>
> There are still a few issues I know of, the Attributes tab seems to delay
> loading and the broker topology diagram is incomplete but feel free to
> suggest any improvements or buglets you come across on this thread.
> Hopefully I can tie up the loose ends soon and raise a PR in the not too
> distant future.
>
> Andy

Reply via email to