[keycloak-dev] public/private api module structure

[Marko Strukelj]

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

One way to split is through package names. 

If that could bring some confusion when using IDEs quick assist / find class for typical classes with same names we could make sure that we prefix common names - instead every SPI having Factory for example we could then have EventFactory, AuthenticationFactory, SAMLFactory ... 

> > 
> > 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
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>