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: DnNode class (was :Re: Creation of a second Subentry cache)
Date Mon, 03 Jan 2011 12:07:04 GMT
On 1/3/11 12:27 PM, Alex Karasulu wrote:
> On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharny<elecharny@gmail.com>wrote:
>
>> (Renamed the thread for clarity)
>>
>> On 1/3/11 9:40 AM, Stefan Seelmann wrote:
>>
>>> On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasulu<akarasulu@apache.org>
>>>   wrote:
>>>
>>>> Not referring to the SchemaUI bundle. In studio we have all of ApacheDS
>>>> available in the embedded ApacheDS plugin bundle. This however is not
>>>> visible outside because it's an OSGi bundle, however there's no reason
>>>> why
>>>> the DnNode class cannot be accessed in a similar fashion through the AP
>>>> UI
>>>> plugin bundle by having a dependency on core-api.
>>>> Essentially studio already uses the entire server in the ApacheDS plugin.
>>>>
>>> It's not visible because the ApacheDS JARs are not added to the bundle
>>> classpath. Instead the ApacheDS plugin just extracts the entire server
>>> to the file system and starts a new java process.
>>>
>>>   What's the big deal in having another bundle depend on core-api for
>>>> managing
>>>> APs?
>>>>
>>> Pierre-Arnaud already added this (and other) ApacheDS artifacts, so
>>> they are available as OSGi bundles.
>>>
>> I have no problem moving DnNode class to core-API, except that it's
>> probably not the right timing to do so.
>
> Well you've been incredibly reticent especially while I provided valid
> strong points for the move. So saying no problem seems very contradictory.
I still believe that there is no valid technical reason for this move. I 
still believe that we will need this class on the client side, without 
having to depend on core-api. I just have no problem getting this class 
moved around as soon as it's present somewhere. If we have to move it 
back to shared later, so be it. I won't block anything in this area 
because it's not relevant. As you said, my personal feelings are not 
important.


> Plus I'm not using my feelings, opinions or saying probably here. I sited
> some valid technical arguments and that's how we operate here in Apache.
Please, I don't need you to lecture me here.

>> Bottom line, I don't really care, as soon as such moves are done when the
>> current work done on AP are completed, in order to ease the merge back to
>> trunk (other wise it will be a nightmare), plus as soon as we check the
>> impact of such moves on studio (and here, i'm not talking about DnNode, but
>> about other potential changes we will have to do in shared before the
>> release).
>>
> SVN allows you to merge code and work in parallel in a branch. No one has to
> wait for someone else to continue their work and merge.
No one has to make it painful for other, as you now perfectly well that 
tree conflicts are a PITA to handle. More than that, we already 
discussed this point earlier : changing shared is anything but urgent 
atm. There is no serious issues in it, and once the last blocking issue 
in the server, namely the AP handling, is fixed, then as I said, we can 
start and cleanup shared.

If you want to help us to fix this AP thing, you are more than welcome.
> If you merge in first, I myself will deal with the cleanup involved on the
> merge back after your AP changes.

This is why I told you it was not urgent. People are working on trunk, I 
do merge back the fixes that are injected into trunk tothe AP branch in 
order to avoid such conflicts later. Shared modifications you are 
currently doing are not entering this area because it's not urgent.

We already had a discussion back in october about Shared refactoring, a 
lot of modifications have been made back then, and I don't remember 
having seen any objection from you back then.

I find it a bit strange to see you pushing as much as you can for minor 
modifications that are not urgent not necessary.

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


Mime
View raw message