Just looked at this possibility. It would mean much bigger number of steps for people to try out examples.

For classic LDAP they will need to: download from webpage, unzip, run, import the LDIF file

However for Kerberos it's much more steps as default ApacheDS setup doesn't have kerberos enabled. So additionally they need to download Apache Directory studio (more than 100 MB download), enable kerberos server through Directory Studio, configure interceptors, sasl principal etc.

Current programmatic configuration used in examples means that people can run the embedded ApacheDS server in single step through mvn exec:java . Much less pain and much easier setup.

Is the separate util/embedded-ldap module really so big issue? Despite manual download and setup, the other possibility to get rid of it may be to duplicate some code for ApacheDS setup into the examples itself. It would mean some code duplication, however util/embedded-ldap module would be removed.

Still I don't like the duplications, my preferred option is to keep as it is.

Marek

On 25/01/16 13:07, Stian Thorgersen wrote:
I know, but the examples should get ApacheDS from https://directory.apache.org/apacheds/, not a hacked/modified version.

On 25 January 2016 at 12:58, Marek Posolda <mposolda@redhat.com> wrote:
Sure, ApacheDS is exactly what we're using in examples and what's used by testsuite by default. Module util/embedded-ldap has dependency on apache-ds and it's just adding few additional fixes and enhancements.

Marek


On 25/01/16 12:48, Stian Thorgersen wrote:
Shouldn't the examples be based on a real LDAP server instead? For example https://directory.apache.org/apacheds/?

On 25 January 2016 at 12:36, Marek Posolda <mposolda@redhat.com> wrote:
On 21/01/16 13:19, Stian Thorgersen wrote:
util/embedded-ldap can we move this to testsuite?
 It's used by both testsuite and examples ("ldap" and "kerberos" examples).

That was main motivation to move them to separate module, so examples are not dependent on testsuite.

Marek


On 21 January 2016 at 13:18, Stian Thorgersen <sthorger@redhat.com> wrote:
saml/saml-core I take it that's used by client and server? Should we just move saml-core to the root? Seems unnecessary to have a parent module with only one module inside.

On 21 January 2016 at 13:08, Stian Thorgersen <sthorger@redhat.com> wrote:


On 20 January 2016 at 23:27, Bill Burke <bburke@redhat.com> wrote:
"backends" (jpa, mongo, infinispan) were consolidated under
keycloak-model-(jpa, mongo, infinispan).

Integration module was moved around into:
adapters/
adapters/oidc
adapters/saml
spi/

connections, broker, social, events etc. were consolidated.

Modules I did not consolidate:

federation/*

I kept federation separate as I'm wondering what will happen with
kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
separate too.

events/syslog
I'm deleting this. Shouldn't have been added in the first place as syslog can be done with the syslog appender for regular logging. Besides no one actually requested it.
 

Not sure if this is something we was removable or not as it depends on a
thirdparty library.

client-registration/*
Moved to integration. It's client lib for client registration service.
 
wildfly/*

Needs to stay as is. It's all specifics to WF and they can't be combined.
 

I don't know much about these modules so I kept them separate.
Stian/Marko can decide what they want to do here.

--
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