----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Sent: Wednesday, 12 August, 2015 6:58:35 PM
Subject: Re: [keycloak-dev] public/private api module structure
On 8/12/2015 10:20 AM, Stian Thorgersen wrote:
> ----- 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.
This is an honest question. Why do they have to figure out what belongs
to what? And why do they care? They will be looking at documentation
There's two types of devs those that reads docs and javadocs and does that don't.
Personally I'm a bit of both I refer to javadocs sometimes, but quite frequently I
look through the source code and that's much simpler if it's modularized. However,
I've thought about it a bit and I think we can achieve the same modularity with
packages and by making sure "keycloak-server-api" mainly contains interfaces.
JBoss, a division of Red Hat