Ldap-API and shared refactoring : is it the right timing ?

[Emmanuel Lecharny <el...@gmail.com>]

  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.

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

thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Ldap-API and shared refactoring : is it the right timing ?

[Kiran Ayyagari <ka...@apache.org>]

On Thu, Jul 8, 2010 at 1:53 PM, Emmanuel Lecharny <el...@gmail.com> 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

Re: Ldap-API and shared refactoring : is it the right timing ?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Emmanuel,

On 8 juil. 2010, at 10:23, 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.

I'm +1, although I also liked the idea of having different modules which helped for the general comprehension and organization of the whole project.
But given the recent problems with projects cyclic dependencies, I believe we only have this solution to solve this issue once and for all...

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

Definitely a good thing... :)


> thoughts ?
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>