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
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, UserFederationProvider etc.
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
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
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
keycloak-dev mailing list