On 9/14/10 12:39 PM, Alex Karasulu wrote:
Hi Emmanuel,
Comments inline...
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).
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.
That was back when we were using Maven 1. Right now, those cyclic
dependencies are gone.
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.
It's already done.
- rename shared to ldap-api
Is everything that is in shared part of the ldap-api?
Most of it.
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.
Absolutely. I moved out any references to MINA in shared-ldap yesterday,
but we still have some coupling in shared-asn1-codec. We might want to
get rid of this coupling before releasing.
At some point, we may want to use something else than MINA, or our users
might want to do so. This was one part of the contract we wanted to
establish with the Sun/OpenDS guys when we started working o the API,
and I think it's still relevant.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
