directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <m...@stefan-seelmann.de>
Subject Re: Unit tests for ldap api classes
Date Sat, 03 May 2014 20:03:33 GMT
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 <mail@stefan-seelmann.de>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
>>>>>
>>>>
> 
> 


Mime
View raw message