directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: Ldap-API and shared refactoring : is it the right timing ?
Date Thu, 08 Jul 2010 08:33:42 GMT
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

View raw message