Keycloak Dev Service doesn't use the Quarkus distribution of Keycloak

Describe the bug

The Keycloak dev service is great, and the Dev UI for auth is very helpful. #17364 is impressive work, but if the Quarkus project doesn’t use the Quarkus distribution of Keycloak, then who will?

Expected behavior

IMO (without much insight into any of the two projects) Keycloak dev mode should default to using Keycloak.X, possibly allowing a toggle to the regular distribution for anyone who gets blocked by the “preview” status.

Actual behavior

Starts regular Keycloak, which uses ~200MB more memory and double the startup time of Keycloak.X, compared to my hack to use Keycloak.X as dev service: https://github.com/Yolean/kubernetes-keycloakx/tree/master/quarkus-dev#keycloakx-for-quarkus-dev-mode

How to Reproduce?

• mvn quarkus:dev from for example https://quarkus.io/guides/security-openid-connect
• Observe the INFO [🐳 ...]] (build-45) Container keycloak started in PT9.315248S
• docker stat to see memory usage

Output of uname -a or ver

No response

Output of java -version

OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.20.04)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.1.0

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.6.3

Additional information

No response

[sberyozkin]

@solsson There is a good chance Keycloak experts will help with improving it - as soon as I can get a custom realm import working with http only I’ll go ahead and finalize the PR such that it works for both WildFly and Keycloak-X containers; in meantime please keep stressing the initial DevServices/UI for Keycloak and let us know what you think (with issues, etc) - thanks

[solsson]

I suppose that assistance from the Keycloak project could be necessary here. I’ve failed to assess the status of the “preview” such as if it’s feature complete or not. However the principle of configuration at build time is a great improvement over the regular keycloak image. Some of the documented env:s there cause an additional appserver start and teardown from the entrypoint, which can delay readiness with minutes. Configuration at build time does make some “quick start” cases impractical though, and i’m not surprised if you’ve concluded that Quarkus would have to push its own downstream keycloak-x image.