Repository navigation
fix: updates to create a java admin client build - #48343
Merged
Merged
Conversation
shawkins
force-pushed
the
iss48340
branch
7 times, most recently
from
April 21, 2026 21:35
9cf23fe to
3465bae
Compare
shawkins
marked this pull request as ready for review
April 21, 2026 21:35
shawkins
marked this pull request as draft
April 21, 2026 22:21
<
8000
div class="TimelineItem-badge">
This was referenced Apr 21, 2026
closes: keycloak#48340 Signed-off-by: Steve Hawkins <shawkins@redhat.com>
Member
There was a problem hiding this comment.
I am fine with changes. One comment regarding a dead dependency in admin-client pom.
Signed-off-by: Steve Hawkins <shawkins@redhat.com>
michalvavrik
approved these changes
Apr 23, 2026
edewit
approved these changes
Apr 23, 2026
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.authz.PolicyEvaluationTest#org.keycloak.testsuite.model.singleUseObject.SingleUseObjectModelTest#testClusterKeycloak CI - Store Model Tests org.keycloak.testsuite.model.user.UserModelTest#testAddRemoveUserConcurrentKeycloak CI - Store Model Tests org.keycloak.testsuite.model.user.UserModelTest#testAddRemoveUserKeycloak CI - Store Model Tests |
vmuzikar
approved these changes
Apr 24, 2026
Contributor
There was a problem hiding this comment.
This looks good. We can later (when we resolve the issues around Java versions) add a dedicated clientV2 method (or something like that) to the root of admin client to avoid using the proxy method.
Closed
sashyo
pushed a commit
to tide-foundation/keycloak-IGA
that referenced
this pull request
Jul 20, 2026
* fix: updates to create a java admin client build closes: keycloak#48340 Signed-off-by: Steve Hawkins <shawkins@redhat.com> * addressing review comments Signed-off-by: Steve Hawkins <shawkins@redhat.com> --------- Signed-off-by: Steve Hawkins <shawkins@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I see the intent behind the ClientsWrapper class, but I don't think we're ready yet to commit to an api like that as it obsures the versioning and is a different realm paradigm than the existing methods.
For now I'd propose opening up the proxy method, as that won't unnecessarily expose anything that we wish to change later with the understanding that the client v2 interfaces aren't yet considered supported (I'm not sure if / where that needs documented).
Comparing with the fabric8 logic you have both methods, such as client.apps().statefulsets() - specifically for v1 statefulsetets, or you can also do client.resources(StatefulSets.class) for the general api.
Another set of changes is to set a lower source compatiblity level. The admin client is using 8, but setting the admin api v2 interfaces to v2 to 11 seems sufficient to have things compile, so I'd start there instead.
As noted in other issues, we still have to make it clearer how we're differentiating between admin api v2 (the new url structure) from the resource specific versions clients v2, v3, etc. - or even if the latter is still a good idea :) cc @michalvavrik
Related to that, our api structuring is not correct. Having a general "ClientsApi clients(String version)" endpoint means that we'll only ever have things that conform to the ClientsApi (v2) contract. It's not even possible to have a truly breaking change.
After this pr, I have changes for the admin client repo that will add the v2 classes.
closes: #48340