directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: API / shared merge
Date Tue, 14 Sep 2010 10:45:58 GMT
Hi Stefan,

On Thu, Sep 9, 2010 at 10:09 PM, Stefan Seelmann <>wrote:

> On Thu, Sep 9, 2010 at 5:11 PM, Emmanuel Lecharny <>
> wrote:
> >  Hi guys,
> >
> > it seems that when I did the big modification (merging all the Messages)
> > last month, I forgot to uncomment the dsml-parser which is part of
> shared.
> >
> > I had it working by pointing to the ldap-api project, as it now depends
> on
> > it, but that was not enough to be able to build it when uncommented in
> the
> > shared/pom.xml file, as shared does not depend on ldap-api.
> >
> > However, in my mind, the next step was to integrate the ldap-api project
> > into shared (well, imo, shared <==> ldap API up to a point).
> >
> > Here is what I suggest we do :
> > - move ldap-client into shared
> > - rename shared to ldap-api
> > - move all the DIR-SHARED issues to DIRAPI
> > - and release ldap-api
> I agree and would like to discuss some more steps before releasing the API:
> - should we rename the package names o.a.d.shared or keep it?

Sometimes I feel this shared thing grew big fast and started gaining things
from everywhere like from the LDAP efforts as well as Kerberos and other
aspects. Maybe we need a good review/tally of our package namespace to see
which direction is best for us.

> - about the number of modules, should we merge some? Especially the
> ldap-schema* modules contain only 10 classes splitted into 3 modules.

Don't think we should worry about the size or contents but rather more about
coherence and coupling issues as well as possible snags we can get into with
potential Maven Module dependency cycles.

We really need to review and map out our existing top level project => maven
module => package layout as well as a nice dependency map of what exists
today to formulate a nice plan as we expand into the future.

> - the shared-ldap module contains some packages that are not directly
> related to a client API: aci, sp, trigger, subtree.Should we still
> keep them in the ldap-api project or move them to a server module?
Yep these are some of the sticking points that I've had in mind as well. We
need to think more about this. This is why this is not such a simple thing
to do with IDE refactoring we must plan or else we're going to have another
mess in the future to clean up yet again. Every time we do this our users
will get pissed off at us and perhaps rightfully so.

> At last before publishing an API we should decide which classes we
> consider as public API and which classes are for internal use only.
Absolutely agree 100% with you on this. API's are not like our internals and
we're going to have to have a contract with our users and manage deprecation
etc. We need to be thorough and careful.

> Thought?
> Kind Regards,
> Stefan

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message