I agree that moving providers to separate module might be clearer, but
not sure if it's easily doable. For example
org.keycloak.provider.ProviderFactory requires KeycloakSession from
org.keycloak.models package, which requires access to all model classes
like RealmProvider, UserProvider etc. So moving might require removing
'dependency' on RealmProvider and UserProvider from KeycloakSession,
which will be quite big refactoring...
So I am like 50/50 whether to move or not. Until that, I suggest that
you put your SPI directly to keycloak-model-api . It already contains
bunch of other basic SPIs like RealmProvider, UserProvider,
On 4.8.2015 07:31, Giriraj Sharma wrote:
IMHO, it will be good if we move the package (org.keycloak.provider)
from keycloak-model-api to some other module which is used as a common
dependency by most other modules (like keycloak-core) .
org.keycloak.provider.* from keycloak-model-api is used by most of
the modules which implement certain Spi.
A module (X) having keycloak-model-api (Y) added as a dependency may
in turn be used by classes or other Spi's in keycloak-model-api (Y)
and thus result into a cyclic dependency.
X dependent on Y for org.keycloak.provider.* classes
Y dependent on X for X specific services/SPI's or classes
keycloak-core is used by many modules but in turn keycloak-core
doesn't uses any of keycloak-* dependency and hence will not result
into any issues like cyclic dependency. So, may be moving
org.keycloak.provider.* from keycloak-model-api to some other(like
keycloak-core) will be helpful or may be a better practice.
If this seems fine, I will be happy to make the required changes :)
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
keycloak-dev mailing list