Reintroduce DevUI for remote dev mode

[mkouba]

Description

DevUI was disabled for remote dev mode in #15560 (old) and #32837 (new). However, I think that it's a very useful feature and it should be re-added in order to make the remote dev mode more usable.

I'm aware of possible security issues but (a) there are use cases where security does not really matter; e.g. using remote dev to develop a quarkus app on a single-board computer (such as RPi) and (b) we could use the management interface with basic auth in order to secure the DevUI.

But looking at DevUIProcessor it seems that the routes produced are not marked as management routes. Is that intentional? CC @phillip-kruger

Implementation ideas

By default, the the DevUI could be disabled for remote dev mode unless the management interface is enabled.

We could also introduce a config knob to enable the DevUI for remote dev mode regardless of whether the management interface is used.

[quarkus-bot]

/cc @cescoffier (devui), @phillip-kruger (devui)

[sberyozkin]

#44464 is related

[phillip-kruger]

But looking at DevUIProcessor it seems that the routes produced are not marked as management routes. Is that intentional?

Dev UI predates management interface, and the management interface targeted prod related services (health / metrics etc), so dev ui was not really considered. Like I said in the other issue, we can probably consider this for remote dev, but I am not sure what the effort will be. Dev UI is bit more complex than for instance a health endpoint. There are multiple things that will have to move:

• The serving of the web components (js + html)
• The serving of the build time data (json)
• The json-rpc (websocket) endpoint
• The mvnpm libraries

There might be more, but this is what I can think of now.

[cescoffier]

The management UI is not reallt design to host the dev UI. It can be done, but will take some work.

[mkouba]

Dev UI is bit more complex than for instance a health endpoint. There are multiple things that will have to move:

So my initial thinking was to mark all routes produced in DevUIProcessor#registerDevUiHandlers() with NonApplicationRootPathBuildItem.Builder.management(). But that's probably not enough.

The management UI is not reallt design to host the dev UI. It can be done, but will take some work.

What exactly is missing?

In any case, the current state - no DevUI for remote development - seems too restrictive to me. We could start with a config knob to enable the DevUI for remote dev mode (something quarkus.live-reload.devui.enabled=false by default). And then consider moving DevUI to management interface. WDYT?

CC @maxandersen @cescoffier @phillip-kruger

BTW all those quarkus.live-reload.* config properties should be IMO something like quarkus.dev-mode.remote.*. The current names are confusing...

[maxandersen]

moving to mgmt isn't the right place to put it is it?
i.e. if I run with mgmt interface enabled during dev - we would then have to change all localhost:8080/q/dev and cross-links ?

BTW all those quarkus.live-reload.* config properties should be IMO something like quarkus.dev-mode.remote.*. The current names are confusing...

wdym here? you don't mean all live-reload settings should be under remote ?

[mkouba]

moving to mgmt isn't the right place to put it is it?
i.e. if I run with mgmt interface enabled during dev - we would then have to change all localhost:8080/q/dev and cross-links ?

Hm, yes that's not ideal. Although we could probably just redirect all q/dev-ui links...

BTW all those quarkus.live-reload.* config properties should be IMO something like quarkus.dev-mode.remote.*. The current names are confusing...

wdym here? you don't mean all live-reload settings should be under remote ?

Sorry, not all only those related to the remote dev mode... or at least something like quarkus.live-reload.remote.password...