directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: ADS 2.0 : what, how and when?
Date Wed, 05 Jan 2011 17:21:27 GMT
On 1/5/11 5:33 PM, Alex Karasulu wrote:
> On Wed, Jan 5, 2011 at 6:22 PM, Emmanuel Lecharny<elecharny@gmail.com>wrote:
>
>> On 1/5/11 5:13 PM, Alex Karasulu wrote:
>>
>>> On Wed, Jan 5, 2011 at 5:48 PM, Alex Karasulu<akarasulu@apache.org>
>>>   wrote:
>>>
>>>   If this is the case then and the client API does not expose any other
>>>> shared interfaces then we're golden here.
>>>>
>>>>
>>>>   OK just looked and this is not the case. The LDAP Client API pulls in
>>> and
>>> exposes for starters things like Entry and DN and Cursor etc which pull in
>>> other API elements in shared. So we're not golden unfortunately.
>>>
>> This is what I called the 'base elements'. And those guys are pretty stable
>> :)
>>
>> Most of them have been refactored 2 years ago and haven't changed a lot
>> since then, hopefully !
>>
>> Cursors have been refactored last year by Stefan too.
>>
>>
> Yes these classes are solid but that's not my point. These classes are in
> the same module and often there are interdependencies between them and other
> classes.
>
> The dependency web in shared ultimately exposes implementation classes.
> These stable classes and interfaces through the web of dependencies is
> pulling in not so stable dependencies.
>
> The way we deal with this is by isolating it out and breaking apart the
> needless dependencies making the dependency picture very clear.
>
> These 'base elements' (which I moved into an experimental ldap-model in my
> branch) are the public API elements in shared and in the ldap client. These
> interfaces are now distributed across multiple modules and have deps on
> implementation classes instead of being isolated.

That's fine with me. Package decoupling and such things have to be done 
before any release, 100% agreed.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message