directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
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 <>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<>
>>  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 ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message