[keycloak-dev] public/private api module structure

[Stian Thorgersen]

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

I believe all spis, factories and provider interfacers are already prefixed.

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