[keycloak-dev] module re-org

[Stian Thorgersen]

On 13 January 2016 at 21:47, Marek Posolda <mposolda at redhat.com> wrote:

> +1 for structure around this. I would personally put every SPI
> implementation, which can be theoretically replaced and which brings any
> dependency into separate module.
>

I agree. A structure based on a major dependency like Mongo, JPA,
FreeMarker, etc makes sense to me.


>
> For example liquibase JpaUpdaterProvider is another module, which I would
> put separately, so there is easy to get rid of liquibase dependency and
> replace with another JPA updater implementation. On the other hand, the
> very basic SPI implementations like BasicTimer doesn't need to be in
> separate module IMO, as it is simple implementation dependent just on pure
> JDK.
>

The JPA stores are pretty dependent on Liquibase so I would just keep them
together. Otherwise we're splitting up a store implementation into multiple
pieces.


>
>
> Marek
>
>
> On 13/01/16 19:14, Stian Thorgersen wrote:
>
> How about:
>
> keycloak-common
> keycloak-common-saml
> keycloak-common-oidc
>
> keycloak-server-spi
> keycloak-server-jpa
> keycloak-server-mongo
> keycloak-server-infinispan
> keycloak-server-freemarker
> keycloak-server-ldap
> keycloak-server-themes
> keycloak-server-wildfly
> keycloak-server-services
>
> All providers that are don't fall into one of the above categories (for
> example timer, protocol mappers, etc..) can just go into
> keycloak-server-services.
>
>
> On 12 January 2016 at 19:44, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On 12 January 2016 at 19:32, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>>
>>>
>>> On 12 January 2016 at 16:26, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On 12 January 2016 at 03:22, Bill Burke < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>> I can't find the original email on this, but we need to do this for
>>>>> 1.9.  I can start doing it one module at a time:
>>>>
>>>>
>>>>> Common:
>>>>> keycloak-common
>>>>> keycloak-common-saml
>>>>> keycloak-common-oidc
>>>>>
>>>>> Libraries server:
>>>>>
>>>>> keycloak-server-spi - all SPI interfaces and common code
>>>>> keycloak-server-saml - all saml server code, broker and protocol
>>>>> plugins
>>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>>> keycloak-server-impl - everything
>>>>>
>>>>
>>>> I'm not 100% sure we should put all implementations of SPIs into
>>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>>> part of the product.
>>>>
>>>> If we put all SPI implementations, including services, into the same
>>>> module we'd end up with one huge module. There's also a risk that we'd end
>>>> up with strong relationships between them, rather than having them properly
>>>> linked via SPI interfaces.
>>>>
>>>> I'm a bit 50/50 on it though.
>>>>
>>>> You do remember how many modules we currently have don't you?
>>>> Minimally, we should have a big SPI module right?
>>>>
>>>
>>> I'm absolutely on board with:
>>>
>>> Common:
>>> keycloak-common
>>> keycloak-common-saml
>>> keycloak-common-oidc
>>>
>>> Libraries server:
>>> keycloak-server-spi
>>>
>>> So we can agree on that, I'm just not 100% sure about a single module
>>> for all SPI implementations and services.
>>>
>>
>> We can go with a single module if you want. Only thing that needs to be
>> separate is Mongo at least for now as it's not going to be supported and we
>> need to be able to remove it easily.
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/1d9c3cac/attachment.html