Continuing the shared modules merge

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

  Hi guys,

as I have merged all the schema modules into shared-ldap-schema, I'm 
continuing to merge the modules that does not deserve to be standalone. 
Here are the next targets :
- shared-ldap-constants should be part of shared-ldap
- shared-ldif should be part of shared-ldap
- shared-ldap-jndi may remain a separate module atm
- shared-ldap-converter should be part of shared-ldap
- shared-cursor should be part of shared-ldap
- shared-asn1 and shared-asn1-codec are an anomaly : right now, I really 
think those two modules should be merged into shared-ldap, but as 
shared-asn1-codec has a dependence on MINA, it's better to keep them 
independent. I would like to be able to get rid of this MINA dependency, 
by defining the MINA references through providers, but this is a 1 day 
effort I don't have the desire to do now. If someone have time to work 
on decoupling shared from MINA completely, that would be a good move 
(well, MINA dependencies could be declared with a scope <test>, but 
otherwise, we should not depend on MINA at all, IMO).

Thoughts ?

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

Re: Continuing the shared modules merge

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

  On 9/17/10 2:59 PM, Stefan Seelmann wrote:
> Sounds good, except one thing: As we have a separate shared-dsml
> module and in your previous mail you said you want to keep it, I
> wonder if it makes sense to keep shared-ldif in a separate module? An
> the other side, LDIF is used all the time when dealing with LDAP.

To me, DSML is a different beast. LDIF is a base component used all over 
the server, and the client obviously.

Don't get me wrong : I don't want to end with a giant shared-ldap module 
containing everything, but limit the number of modules we are dealing 
with. At the end of this refactoring, we should keep :
- shared-ldap
- shared-dsml
- shared-jndi
- shared-i18n

and that's it.

Another aspect is that I'm not only doing this refactory to gather the 
maximum classes in a singe module, but when we will rename shared to 
API, it will generate less work and problems.

Also I consider we went too far with the multiplication of modules. The 
server is probably a different problem though, as the modules are used 
to help us keeping each concern in an isolated component.

We should keep in mind one thing when creating a module : is this module 
standalone, or can be used on one side only (ie, client or server) ? If 
the answer is no to those two questions, I think we should start 
thinking about merging them.

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

Re: Continuing the shared modules merge

[Stefan Seelmann <se...@apache.org>]

Sounds good, except one thing: As we have a separate shared-dsml
module and in your previous mail you said you want to keep it, I
wonder if it makes sense to keep shared-ldif in a separate module? An
the other side, LDIF is used all the time when dealing with LDAP.

Kind Regards,
Stefan


On Fri, Sep 17, 2010 at 2:49 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>  Hi guys,
>
> as I have merged all the schema modules into shared-ldap-schema, I'm
> continuing to merge the modules that does not deserve to be standalone. Here
> are the next targets :
> - shared-ldap-constants should be part of shared-ldap
> - shared-ldif should be part of shared-ldap
> - shared-ldap-jndi may remain a separate module atm
> - shared-ldap-converter should be part of shared-ldap
> - shared-cursor should be part of shared-ldap
> - shared-asn1 and shared-asn1-codec are an anomaly : right now, I really
> think those two modules should be merged into shared-ldap, but as
> shared-asn1-codec has a dependence on MINA, it's better to keep them
> independent. I would like to be able to get rid of this MINA dependency, by
> defining the MINA references through providers, but this is a 1 day effort I
> don't have the desire to do now. If someone have time to work on decoupling
> shared from MINA completely, that would be a good move (well, MINA
> dependencies could be declared with a scope <test>, but otherwise, we should
> not depend on MINA at all, IMO).
>
> Thoughts ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>

Re: Continuing the shared modules merge

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

+1
Sounds good to me.

Regards,
Pierre-Arnaud

On 17 sept. 2010, at 14:49, Emmanuel Lecharny wrote:

> Hi guys,
> 
> as I have merged all the schema modules into shared-ldap-schema, I'm continuing to merge the modules that does not deserve to be standalone. Here are the next targets :
> - shared-ldap-constants should be part of shared-ldap
> - shared-ldif should be part of shared-ldap
> - shared-ldap-jndi may remain a separate module atm
> - shared-ldap-converter should be part of shared-ldap
> - shared-cursor should be part of shared-ldap
> - shared-asn1 and shared-asn1-codec are an anomaly : right now, I really think those two modules should be merged into shared-ldap, but as shared-asn1-codec has a dependence on MINA, it's better to keep them independent. I would like to be able to get rid of this MINA dependency, by defining the MINA references through providers, but this is a 1 day effort I don't have the desire to do now. If someone have time to work on decoupling shared from MINA completely, that would be a good move (well, MINA dependencies could be declared with a scope <test>, but otherwise, we should not depend on MINA at all, IMO).
> 
> Thoughts ?
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>