Improve developer experience of remote-dev

[sdaschner]

Description We should consider improving the developer experience of containerized workflows:

• If developers run multiple contains locally during development, e.g. databases, external systems, mockservers, Quarkus dev mode should be supported easier to be run in Docker containers.
• Developers might need to run a Quarkus (dev mode) inside a container, that is connected to the (cluster / Docker) network, and can access other services, while source file changes get reflected as well.
• We should provide examples / shortcuts how to quickly build a remote dev image / environment (e.g. using a Docker image with Java+Maven+app, or easier).
• Quarkus remote-dev doesn't seem to support pom dependency changes (#6100).

Questions / possible implementation

• Is it only possible to have the reload capabilities of dev mode with Maven (quarkus:dev)
• Or could we also start Quarkus from Java / JAR, and have a remote-dev mode attached to it?
• For the latter we could point quarkus:remote-dev to a (containerized) Java runtime, and have the same capabilities, without packaging Java + Maven into a Docker image.

[geoand]

cc @maxandersen

[maxandersen]

Hi @sdaschner much of this is captured in epic #5917 but I got a few questions to clarify your comments.

• If developers run multiple contains locally during development, e.g. databases, external systems, mockservers, Quarkus dev mode should be supported easier to be run in Docker containers.

Do you just mean that it would be nice if we could run quarkus dev mode without requiring containers to include the build tools like maven or gradle ? then yes - that’s what #5917 is about. If not, can you clarify what you mean by "easier"

• Developers might need to run a Quarkus (dev mode) inside a container, that is connected to the (cluster / Docker) network, and can access other services, while source file changes get reflected as well.

That is the exact usecase binary devmode (#5917) and remote-devmode is for so I hope that is captured.

• Is it only possible to have the reload capabilities of dev mode with Maven (quarkus:dev)

No, you can do it with gradle too.

• Or could we also start Quarkus from Java / JAR, and have a remote-dev mode attached to it?

In #5917 we got notion of "binary devmode" that will work on a binary level so when running in the container we don't need the build tools but just let your laptop do the work.

[sdaschner]

Thanks @maxandersen!

Do you just mean that it would be nice if we could run quarkus dev mode without requiring containers to include the build tools like maven or gradle ? then yes - that’s what #5917 is about. If not, can you clarify what you mean by "easier"

Yes, and also a leaner way to start that container in the first place, e.g. to use the same Docker image like the production app (if even possible), so the users don't have to craft a second Dockerfile for that local dev mode. E.g. that users can simply docker run [<my-special-networking-and-docker-confs>] <my-usual-image> <maybe-different-command> and then "connect" to that container from :remote-dev.

No, you can do it with gradle too.

Ok, you're right, I meant, with Maven from my build tool :)

Yes, I'm pretty sure we're on the same page. So what I want is:

• I start a Docker container from an image (ideally my production image, so no extra Dockerfile) with special networking / mounts
• I use :remote-dev (or a similar way) to detect source changes which are reflected into the running container
• I test the changes manually or by connecting end-to-end tests to my container

Now, this works manually if I create an image similar to this, then run the container as desired and connect to it (see scripts).

[maxandersen]

its not settle yet how it will work yet but for the usecase of being able to use same image as production there would be no build tools nor any sources thus it would need what I call "binary devmode" and that would preferably just be a flag to the launch.

if we don't get that soon then yes, we should make it easy to have images with the right stuff built in; but then the base images would be quite much bigger so users would probably want to have two different ones.

[sdaschner]

In case there's something I can help with, lmk