On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharny <email@example.com>
(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<firstname.lastname@example.org> wrote:
I have no problem moving DnNode class to core-API, except that it's probably not the right timing to do so.
Not referring to the SchemaUI bundle. In studio we have all of ApacheDS
It's not visible because the ApacheDS JARs are not added to the bundle
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.
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
Pierre-Arnaud already added this (and other) ApacheDS artifacts, so
they are available as OSGi bundles.
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.