I agree and would like to discuss some more steps before releasing the API:On Thu, Sep 9, 2010 at 5:11 PM, Emmanuel Lecharny <firstname.lastname@example.org> 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
- should we rename the package names o.a.d.shared or keep it?
- about the number of modules, should we merge some? Especially the
ldap-schema* modules contain only 10 classes splitted into 3 modules.
- 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?
At last before publishing an API we should decide which classes we
consider as public API and which classes are for internal use only.