directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: DnNode class (was :Re: Creation of a second Subentry cache)
Date Mon, 03 Jan 2011 11:27:08 GMT
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.

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.


> What bugs me is that this class was added in shared way before the core-api
> module was created. May be we forgot to move it back then. I do feel we may
> use it for other purposes than just the server, not forcing a potential user
> to add core-api in its dependencies, but anyway, it's not a big deal.
>
>
Again what "bugs", and what you "feel" are not how we operate.


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

If you merge in first, I myself will deal with the cleanup involved on the
merge back after your AP changes.


> The best would be to create a JIRA suggesting moving DnNode, so that we can
> track such moves and impacts.
>

This is a simple 2 second class move in my branch which tracks the change.
No need to clutter up JIRA with every little infinitesimal code change.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message