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@redhat.com> wrote:


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


On 1/13/2016 2:02 PM, Stian Thorgersen wrote:


On 13 January 2016 at 20:00, Bill Burke <bburke@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@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@redhat.com> wrote:


On 12 January 2016 at 19:32, Stian Thorgersen <sthorger@redhat.com> wrote:


On 12 January 2016 at 16:26, Bill Burke <bburke@redhat.com> wrote:


On 1/12/2016 2:45 AM, Stian Thorgersen wrote:


On 12 January 2016 at 03:22, Bill Burke <bburke@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 Hat
http://bill.burkecentral.com




-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com