Still have not read into the entire thread but I wanted to give some background that you might already be aware of regarding the shared project. More inline ...
On Thu, Sep 9, 2010 at 6:11 PM, Emmanuel Lecharny <email@example.com>
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).
For history sake, note that the shared project started first as a Maven Module instead of a full on project at the same level as ApacheDS and Studio. Then we converted it into a full project as we realized we wanted to factor out more common code that can be reused. However originally shared appeared to solve some issues we were having with Maven Module dependency cycles.
Here is what I suggest we do :
- move ldap-client into shared
Makes sense sine ldap-client will be reused (hence shared) by other projects like Studio and ApacheDS.
- rename shared to ldap-api
Is everything that is in shared part of the ldap-api? Also note that we might want a simple API jar/bundle with the public interfaces and perhaps without connection providers so the implementation can be swapped in and out as needed sort of like the JNDI provider architecture.
- move all the DIR-SHARED issues to DIRAPI
- and release ldap-api
Continuing to read the thread after vacation ... will respond to each point where relevant.