[keycloak-dev] module re-org

[Stian Thorgersen]

Good - changing to Jackson2 is fun. They've changed all package names,
Maven groupId and artifactIds and also done a fair bit of refactoring to
classes. 162 files changes!

On 13 January 2016 at 20:44, Bill Burke <bburke at redhat.com> wrote:

> I'm working on removing most of our nefarious redirects in the auth flow.
>
>
> On 1/13/2016 2:38 PM, Stian Thorgersen wrote:
>
> BTW I'm doing the switch from Jackson to Jackson2 now, so hope you haven't
> started this yet. I'm touching classes everywhere :/
>
> On 13 January 2016 at 20:37, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On 13 January 2016 at 20:17, Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com> wrote:
>>
>>>
>>>
>>> On 1/13/2016 2:02 PM, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 13 January 2016 at 20:00, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>> Because it isn't something that would ever be removed like JPA or mongo?
>>>>
>>>
>>> Actually, in theory it could. That's why I thought it was a sensible
>>> separation. It all relies on Freemarker so if we decided to use something
>>> else or to support another templating mechanism as well. Or even to stop
>>> using templates and use AngularJS+rest.
>>>
>>>
>>>
>>> No way it is removed for a LOONNGGG time.  Too many users are dependent
>>> on it now.  Our own codebase depends on it too.
>>>
>>
>> Sure, I'm just saying in theory. My vote goes to keep it separate.
>>
>>
>>>
>>>
>>>> Themes would just be .js and .html and .css right?
>>>>
>>>
>>> Yep. I think it's worth keeping them separate.
>>>
>>>
>>>>
>>>>
>>>> On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
>>>>
>>>> It seems like a logically grouping. Is there a reason you don't want it
>>>> separate?
>>>>
>>>> On 13 January 2016 at 19:17, Bill Burke < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>> Why do you want freemarker separate?
>>>>>
>>>>>
>>>>> On 1/13/2016 1:14 PM, 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>
>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/f4582118/attachment-0001.html