On 02/10/15 08:49, Stian Thorgersen wrote:
We need to reorganize the modules soon. Things make even less sense now.

How about:

* keycloak-common - common classes re-used by both client and server
* keycloak-client-api - client specific interfaces
* keycloak-server-api - server specific interfaces, including spi and providers

Then we also would have:
* keycloak-json - common json classes (json representations, jwt utils, etc.)
* keycloak-oidc - common OpenID Connect classes
* keycloak-saml - common SAML classes

Most SPI implementations would be moved into keycloak-server, other than those that needs to be pluggable. The SPI implementations that should be in separate modules are:

* Mongo
* JPA - we can combine Liquibase and JPA into one
* Social providers
* Anything else?
LDAP and Kerberos federation providers? We don't want them to be available in "minimal" distribution right?

But I am not sure as Kerberos authenticator is available by default in browser authenticationFlow (even if disabled by default). When someone enables it and LDAP/Kerberos federation provider is not available, it won't work.

Marek


On 1 October 2015 at 20:58, Bill Burke <bburke@redhat.com> wrote:
The SAML adapter had some dependencies on classes within keycloak-core.
  Unfortunately though, keycloak-core brings in Jackson JSON parser.
So, I split out keycloak-core into keycloak-common and keycloak-core.

PR is pending, but it should be in when the Europeans wake up.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev



_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev