Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 74.125.82.177 as permitted sender)
Message-ID: <53653011.1020201@gmail.com>
Date: Sat, 03 May 2014 20:06:09 +0200
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Unit tests for ldap api classes
References: 
 <CAEDoG7Ao3RmE9xFg2n8vnp4W9RQLme39ooDF9jWqqG33xT6WGg@mail.gmail.com>
	<53652002.4090000@stefan-seelmann.de>
 <CAEDoG7Cb1SpDWcPwg=UyeW3+SxtwyLKrj9Tuvwv7ndddno_5Fw@mail.gmail.com>
 <53652452.4040600@stefan-seelmann.de>
In-Reply-To: <53652452.4040600@stefan-seelmann.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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
>>>>
>>>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com