Here is a proposal based on a quick overview of the code with, I hope, enough explanations so that it makes sense.
The keycloak-spring-boot-adapter
is the code that holds the auto-configuration as far as I can see so it would be nicer to name it that way. I'd suggest keycloack-spring-boot-autoconfigure
but it's really not important.
KeycloakSpringBootConfiguration
should be renamed to KeycloakAutoConfiguration
What is important is that rather than taking dependencies and patching them in a shaded jar at that level, you should take that decision in the starter, leaving all that business out of the autoconfigure module. Here is what I suggests:
- The web container adapter must be with
optional
scope - All the provided-scoped dependencies are wrong. These are not provided, these "might" be available at runtime and the auto-configuration will react to it
Questions:
- What is
keycloak-undertow-adapter-spi
and why is it explicitely defined there as provided? Who's providing it?
I'd create a separate project whose purpose is to contain the various servlet container integrations. It can be named whatever you want but something like keycloack-container-adapters
might work. Just depend on the adapters you want to ship, mark them provided and build a jar that contains them. This module shouldn't have any code in it.
Now that I see keycloak-spring-security-adapter
, I understand the problem. You really have two integrations. One that is purely based on spring security (and doesn't seem to use spring boot at all) and one thing that bootstraps everything.
It's totally unclear to me how you auto-configure the security part of Keycloack but, looking at the dependencies, it looks pretty obvious that you can pretend spring-security is an optional dep. Not only you'll break existing use cases but there are much more dependencies that are required there.
So you should probably keep what you have on master at the moment
So keycloack-default-spring-boot-starter
should do the following IMO bring keycloack-spring-boot-autoconfigure
, keycloack-container-adapters
and keycloack-spring-security-adapter
in compile scope.
Use cases that should work:
- If you add
spring-boot-starter-web
and any of the supporter containers, it should work with the Spring Security integration - If you exclude
keycloack-spring-security-adapter
then you should have the "Keycloack without Spring Security" use case