directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lucas Theisen <>
Subject Re: Unit tests for ldap api classes
Date Sun, 04 May 2014 20:27:14 GMT
My original proposal was to

1: Join the client and the tests for the client.
2: Organize the code

As to item 1, there is great value in that.  You can build the module on
its own and have assurance that it is correct.  As it stands right now, you
have to build/install the client, then remember to build the server to run
the unit tests to verify that it worked.  That feels really wonky.  As to
item 2, just guessing from the folder structure in svn, it seems like it
was intended to be 3 parts, a server, a client, and shared code.  So I
guess I was just wondering if we should do that.  Anyway, I'm not sure I
understand enough to have a strong opinion on this, but that's my 2 cents.

On May 4, 2014 2:37 PM, "Kiran Ayyagari" <> wrote:

> On Sun, May 4, 2014 at 9:49 PM, Stefan Seelmann <>wrote:
>> On 05/04/2014 01:33 AM, Emmanuel Lécharny wrote:
>> > Ok, but why should we move api-ldap-client-api to clients/trunk/ldap ?
>> >
>> > What I had in mind was just to move aâcheds/ldap-client-test to
>> > client/trunk/ldap. In this case, we should not have any cyclic
>> dependency.
>> Oh, then I misunderstood you. I thought client/trunk/ldap should contain
>> both, productive and test code for the LDAP client API.
>> AFAI, this is what Lucas was proposing and it can be done provided the
> -test module's pom.xml
> alone contains the apacheds dependencies
> If the main idea was to just have -tests in the same folder as
> -ldap-client then IMHO it offers nothing
> from a developer pov.
> and I am neutral to the idea of creating a new 'clients' branch, cause
> this is not going to solve anything
> except annoying people with broken svn links in their workspaces (which I
> personally don't like).
> Kind Regards,
>> Stefan
> --
> Kiran Ayyagari

View raw message