Make compatible with new Jakarta packaging, rather than javax

GregJohnStewart commented 1 year ago

Description

Quarkus just migrated to use the newer Jakarta based packaging schemes with Quarkus 3, and thus does not have access to javax.* packages. When using this testcontainer in Quarkus 3, errors related to not having javax.* packages are thrown on startup.

Example:

https://github.com/GregJohnStewart/quarkus-proofs/tree/main/34027-keycloak

Running ./gradlew test on this project results in an error:

Caused by: java.lang.NoClassDefFoundError: javax/ws/rs/client/ClientBuilder
    at org.keycloak.admin.client.ClientBuilderWrapper.create(ClientBuilderWrapper.java:29)
    at org.keycloak.admin.client.spi.ResteasyClientClassicProvider.newRestEasyClient(ResteasyClientClassicProvider.java:35)
    at org.keycloak.admin.client.Keycloak.newRestEasyClient(Keycloak.java:98)
    at org.keycloak.admin.client.Keycloak.<init>(Keycloak.java:89)
    at org.keycloak.admin.client.KeycloakBuilder.build(KeycloakBuilder.java:152)
    at org.acme.KeycloakServerManager.start(KeycloakServerManager.java:74)
    at io.quarkus.test.common.TestResourceManager$TestResourceEntryRunnable.run(TestResourceManager.java:492)
    at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:833)

It might just be a case of swapping to a newer version of the keycloak admin client?

Motivation

No response

Details

No response

dasniko commented 1 year ago

Thanks for this issue.

This is not as easy as it sounds... by doing so, it would break the projects which are not yet on jakarta.* packages and still rely on javax.* packages. By not doing so, the projects using the latest dependencies/versions of other frameworks have problems.

Currently, Keycloak 21.x is still on Quarkus 2.x. It seems that the next major release might be on Quarkus 3.x. This would be a chance to introduce a breaking change and go/maintain only the jakarta.* namespace. But I have to think about the best way, to support most of the users, and not to have to maintain too much stuff at the same time.

GregJohnStewart commented 1 year ago

It is an unfortunate issue for sure, many breaking changes to determine when to make...

I know the Quarkus folks have their devservice for Keycloak working with Quarkus 3, but unsure how it's setup or what underlying container it uses. I don't use that particular extension though, so here I am

GregJohnStewart commented 1 year ago

I've been through it up/down/around every which way, but can't seem to get things working without this test container... maybe go down the route of the admin client and make a parallel project for jakarta users? Would be great to have as going forward it will be the way of things

https://central.sonatype.com/artifact/org.keycloak/keycloak-admin-client-jakarta/21.1.2

dasniko / testcontainers-keycloak