On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharny <[email protected]>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<[email protected]> >> 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
