directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: Ldap-API and shared refactoring : is it the right timing ?
Date Thu, 08 Jul 2010 08:26:42 GMT
On Thu, Jul 8, 2010 at 1:53 PM, Emmanuel Lecharny <> wrote:
>  Hi guys,
> the Ldap APIhas grown a bit since its inception, and I'm wondering if it's
> not a good timing to move to the next step : merging shared into LDAP-API ?
> The rason is that shared *is* a major part of the LDAP-API, and from a user
> standpoint, it makes no sense to have 2 jars to declare in order to use the
> API (ldap-api.jar and shared-all.jar).
> One other thing we have to think about is the multiplication of shared sub
> modules. We now have 16 submodules, one of them just to create a big jar
> from all those submodules.
> It's also annoying when it comes to make LDAP classes schema aware (I'm
> thinking about ACI, subtree, filters, and more important, DN), because the
> schema manager is declared in shard-schema-manager module, which depends on
> shared, and if you want to test it, you depeds on another module (
> schema-loader ), inducing some more cyclic dependencies.
> I think that there is no reason to have more than one module for everything.
> This would be the LDAP-API module, containing classes and tests from all the
> 14 shared modules, plus the 2 ldap-api modules.
+1, sounds good to me
I think ldap-client-test remains a separate module cause it depends on
both shared and apacheds

> Btw, it will bring an extra advantage when we will move to OSGi : OSGi does
> not like when 2 modules have 2 classes withing the same package...
if this makes OSGifying server easy then a BIG +1

Kiran Ayyagari

View raw message