[keycloak-dev] public/private api module structure

Stian Thorgersen stian at redhat.com
Wed Aug 12 10:20:44 EDT 2015



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 August, 2015 3:38:31 PM
> Subject: Re: [keycloak-dev] public/private api module structure
> 
> 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.

For users if they included a single module/jar with the apis for all SPIs they would then have to figure out what belongs to what. That's where I think it's cleaner to split it up.

> 
> 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.

We would still need to create separate modules for implementations of the SPIs.

Another thing is that by combining lots of things into one place you make the code less modular and harder to use, especially for those less familiar with the code.

> 
> 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
> 


More information about the keycloak-dev mailing list