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, 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 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 :)

Giriraj Sharma, 
Department of Computer Science 
National Institute of Technology Hamirpur 
Himachal Pradesh, India 177005

keycloak-dev mailing list