Hi Emmanuel, yes, I think your proposal makes sense.
However I still see some circular dependencies that needs to be solved. Kind Regards, Stefan On 05/03/2014 08:06 PM, Emmanuel Lécharny wrote: > Hi Lucas, Stefan, > > there is an old (4 years !) sub-project which was created for this exact > purpose : > > http://svn.apache.org/viewvc/directory/clients/ldap/ > > If you look at the tags directory, there is some code in it. Since then, > we moved he code into apacheds/ldap-api-client. > > I do think it would be a good idea to move back the client code where it > deserves to be. > > Also note that this hierarchy is quite a mess : > > directory/ > clients > branches > kerberos-2.0 (probably the only valid directory) > client > password > realm > kerberos (dead) > branches (dead) > alex-refzctoring (dead) > kerberos-value (dead) > tags (dead) > trunk (dead) > ldap > branches (dead) > tags > 0.1 (4 years old) > trunk (dead) > trunk > kerberos (5 years old) > client > password > realm > ldap (7 years old) > > At this point, I'm +1 to move the client code into the clients > directory, assuming we cleanup the current mess. We should keep the > kerberos-2.0 and ldap directory, but only keep the kerberos-2.0 code. > The resulting repo would be : > > directory/ > clients > branches > kerberos > ldap > tags > kerberos > ldap > trunk > kerberos > ldap > > I'm sure that Kiran can provide some insight regarding the kerberos code > which is present there. > > We also shoudl add some externals in the main project : > directory/apacheds/trunk-with-dependencies/ > svn:externals > apacheds https://svn.apache.org/repos/asf/directory/apacheds/trunk > shared https://svn.apache.org/repos/asf/directory/shared/trunk > project https://svn.apache.org/repos/asf/directory/project/trunk > kerberos-client > https://svn.apache.org/repos/asf/directory/clients/kerberos/trunk > -----> Should be > https://svn.apache.org/repos/asf/directory/clients/trunk/kerberos > ldap-client > https://svn.apache.org/repos/asf/directory/clients/kerberos/trunk > -----> Should be > https://svn.apache.org/repos/asf/directory/clients/trunk/ldap > checkstyle-configuration > https://svn.apache.org/repos/asf/directory/buildtools/checkstyle-configuration/trunk > junit-addons > https://svn.apache.org/repos/asf/directory/buildtools/junit-addons/trunk > apacheds-manuals > https://svn.apache.org/repos/asf/directory/documentation/apacheds-manuals/trunk > > -----> Should probably be removed ??? Or is it to generate PDFs ? > > > WDYT ? > > > > Le 5/3/14 7:16 PM, Stefan Seelmann a écrit : >> 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 >>>>> >>>> > >
