(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. 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.
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).
The best would be to create a JIRA suggesting moving DnNode, so that we
can track such moves and impacts.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
