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(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 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:
> 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
> keycloak-dev mailing list
JBoss, a division of Red Hat