[keycloak-dev] public/private api module structure

[Bill Burke]

Users then have to figure out and know which modules/artifacts to 
import.  We have Authentication SPI, Event SPI, Model, Federation SPI, 
core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI, 
Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add 
the protocol mapper SPI, then we also need to include SAML and OIDC 
public APIs too.  Our total is 10 now.  Then we might eventually want to 
make our Login Protocol and Identity Broker SPI public, and add an SPI 
for Account extensions which would force us to add the 
AccoutnFormProvider SPI too.

That's potentially 14 different public modules.

Finally, it is a pain in the ass for us to add any new SPIs as we have 
to wade through all the wildfly module dependencies in the 3 different 
places they are defined.  We've been creating new SPIs at least once a 
month, sometimes more.

On 8/12/2015 9:04 AM, Stian Thorgersen wrote:
> I'm not convinced..
>
> We'd still have to have separate modules for implementations of an SPI, so it would only reduce the amount of modules somewhat. Besides how often do we create new SPIs?
>
> For users I think having it separate is better as they can more easily see what classes are relevant to the provider they are implementing.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 12 August, 2015 2:50:49 PM
>> Subject: [keycloak-dev] public/private api module structure
>>
>> I was thinking we'd have a more course-grain module structure for public
>> apis.  We have a crap load of SPIs and having a module for each of them
>> is a pain for the user and us in creating/maintaining poms as well as
>> creating maintaing JBoss modules.  Something like:
>>
>> keycloak-core-api
>> keycloak-server-api
>> keycloak-client-api
>>
>> and
>>
>> keycloak-saml-api
>> keycloak-oidc-api
>>
>> protocol APIs would be for the case where users need to access the raw
>> SAML document or JWT.
>>
>> These API modules would only contain public APIs and helper classes.  we
>> can consolidate and/or separate internal implementation classes into any
>> structure we want with the thought process being that we would organize
>> these modules so that we have the option to remove features as needed to
>> make a smaller distro.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com