directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: API / shared merge
Date Fri, 10 Sep 2010 09:36:26 GMT

On 9 sept. 2010, at 23:59, Emmanuel Lecharny wrote:

> On 9/9/10 9: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?
> IMO, we should rename it to something like ldapApi


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


>> - 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?
> aci are likely to be used on the client side, as you may want to manipulate them on the
browser. The very same for subtree.
> sp and trigger is a bit different, but again, as this is up to the 'client' to inject
SP and triggers into the server, I *think* they might remain on the client API.

+1 but maybe with a package name that reflects that it is related to ApacheDS (eg. '[...].apacheds.aci.[...]').

>> 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.



> -- 
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message