On Fri, Apr 10, 2009 at 11:32 AM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Alex Karasulu wrote:
Hi all,

I've been looking at the packages in the apacheds project and as you can
imagine many things grew wild out of short term efforts to get things done.
Before we move forward with a 2.0 and even sooner before considering any
kind of use for OSGi we need to clean up this package structure and have
some order.  From then on we can take care in how we organize things.
 
I agree. I think that at some point, we were so focused to get 2.0 out that we dismissed any reorganization.

I'd like to open a discussion about how best to organize our package
structure.  I'll seed it by listing my objectives:

(1) cleanup unused modules and packages
(2) split out interfaces from implementations into their own packages and
modules
 
I think we also have to check if we really need some of the interfaces we have, when there is only one implementation...

In most cases I would agree with you.  But in general having an interface is safer for the time being until later you realize you will not have more than one implementation. 
 

(3) have a consistent scheme for naming and allocating sub packages under
o.a.d.server.core and o.a.d.server

Our inherent policy was to use o.a.d.server.core.* for packages associated
with the DirectoryService which did not require any network access.  It was
for everything needed to store and manage LDAP entries and conduct LDAP
operations on them without having to go over the wire.  The o.a.d.server.*
packages minus o.a.d.server.core.* was for anything above this layer that
depended on it and used some kind of networking like the LdapService and the
AuthenticationService (in the protocol-kerberos module).
 Over time with most developers working in this project this convention
started to get mixed up.  I was wondering if this convention is worth
keeping or something beter can be proposed.  If we keep this convention I
will cleanup and make sure everything follows it.

Next I would like to have a consistent naming scheme for the modules.  Any
ideas here?

I think we should add a 'protocol' between 'server' and 'ldap'

That might be a good idea.  I was also wondering about nesting again where you have multiproject directories under apacheds for things like protocols, core, ldap, kerberos etc.  But then again kerberos will come out of apacheds when we bud it off as it's own project.
 

server-replication
 org.apache.directory.server.replication
 org.apache.directory.server.replication.configuration
 
It will be removed, and renamed to syncrepl. Now, should it be part of core ?

Probably not.  I think it's networked and part of ldap/server as we discussed.

xdbm-base
 org.apache.directory.server.xdbm
 org.apache.directory.server.xdbm.search

xdbm-search
 org.apache.directory.server.xdbm
 org.apache.directory.server.xdbm.search
 org.apache.directory.server.xdbm.search.impl

xdbm-tools
 org.apache.directory.server.xdbm
 org.apache.directory.server.xdbm.tools
 org.apache.directory.server.xdbm.tools.ui
 
Why is xdbm not part of core ?

Yeah it should be probably.  But I'm beginning to think that with nesting we can do away with this *.core and *.server package naming scheme and module names with core-* or server-*.  I don't know but these were some things I wanted to have a good discussion about.

I just want something clean, simple, easy to intuit and can last forever we don't have to ever deal with this overhead again.

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org