On 1/3/11 12:27 PM, Alex Karasulu wrote:
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.
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
