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<[email protected]> >> 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
+1 >> - 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. +1 >> - 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. 'org.apache.directory.ldapapi.[...].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. +1 Regards, Pierre-Arnaud > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
