Hi Lucas, I see the benefit of your approach, and maybe others already thought about that. But maybe it is not so easy.
The client module would depend on many apacheds modules. And currently many apacheds modules depend on the ldap-client-api module: $ find * -name pom.xml | xargs grep -l api-ldap-client-api core-api/pom.xml core-integ/pom.xml http-directory-bridge/pom.xml interceptors/hash/pom.xml interceptors/logger/pom.xml interceptors/authn/pom.xml kerberos-test/pom.xml ldap-client-test/pom.xml mmr-tests/pom.xml protocol-ldap/pom.xml server-integ/pom.xml I'm not sure if all of them really need the ldap-client-api module. But to refactor is is quite some effort. I won't stop you from trying, if you succeed I think that would be great :) Kind Regards, Stefan On 05/03/2014 07:05 PM, Lucas Theisen wrote: > Hi Stefan, > > Thank you, I believe I knew that already, but was drawing a blank this > morning. > > Should we still consider extracting out another subproject that would be a > peer of apacheds and shared. It would basically be the shared/ldap/client > branch. Then both this new client subproject and the apacheds subproject > could depend on shared, as well as client depending on server so that it > could contain its own unit tests. > > Its just a thought, and I am quite likely missing some reason why we don't > do this, but it seems like it would be a good idea. > > Thanks, > Lucas > > > On Sat, May 3, 2014 at 12:57 PM, Stefan Seelmann > <[email protected]>wrote: > >> Hi Lucas, >> >> the LDAP API integration tests are in apacheds/ldap-client-api, for the >> exact reason you mentioned. >> >> Kind Regards, >> Stefan >> >> On 05/03/2014 06:45 PM, Lucas Theisen wrote: >>> Hi All, >>> >>> I am working on LdapConnectionTemplate ( >>> https://issues.apache.org/jira/browse/DIRAPI-163) and am not quite sure >>> where to put unit tests. It appears that none of the ldap api artifacts >>> depend on apacheds server artifacts. I am wondering if this is a hard >>> requirement? And if so, how do you test the functionality of your apis? >>> It seems that one of the major benefits of an embeddable server like >>> apacheds is that it can be used for unit tests, but if we cannot even use >>> it for our own unit tests... >>> >>> I know I could put some tests in server-integ, but that seems very wrong >>> for testing new ldap api features. If this is because of circular >>> dependencies (server depends on api, so api cannot depend on server), >> then >>> perhaps we should refactor. Maybe move the truly shared stuff (like >> model >>> and what not) into a shared library, and all the api stuff (like >>> connections) into another. What do you think? >>> >>> Thanks, >>> Lucas >>> >> >> >
