----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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,
> 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
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
> 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(a)redhat.com>
> >> To: keycloak-dev(a)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
> >> 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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> Bill Burke
> JBoss, a division of Red Hat
keycloak-dev mailing list