Hi Guillaume,
I like the abstraction from console and jline in your proposal.
The extender pattern in fact solves the classloading problem. So you can
now hide the impl classes. As the extender is independent of the user
framework
it is of course also "compatible" to other frameworks.
The problem with this aproach is that you force people to use the
extender and our quite unusual DI implementation
As the impls are hidden now there is no way to use the API without also
using the extender. For karaf itself this should not pose a big problem.
For external implementations I am not sure if it is a good fit. Some
limitation I see in the extender is that it has a very limited set of
injection possibilities.
You can only inject OSGi services. In camparison in the gogo API case
you could use your user framework to inject configuration and also
private beans when using it with blueprint.
Btw. I do not propose to extend the DI support in the extender. I am
fine with this limitation but we have to be aware of it.
If we additionally include support for gogo style commands with the
parameter style like discussed then we should have a good solution. So
internally we can use the
API you propose and externally people can decide if they want to code
against the extended gogo API (with completion) based on services or
against the karaf API based on the extender.
Christian
On 26.02.2014 10:50, Guillaume Nodet wrote:
The classloader problem is mostly because we don't use an extender.
Blueprint should be able to hide the internal classes used, and that's
actually the case because no bundle sees the BlueprintCommand which is
used. DS is slightly different as it can not contribute its own classes,
where blueprint namespace handlers can.
So I really think using an extender would solve the whole problem I think.
I've just spent a bit of time drafting a cleaner API for commands. The
main problem with the current state is that there was no clean API written
at the very beginning and things have evolved quite a bit. In addition,
gogo and jline leak into our API which is not really good.
So I'd like to discuss the following small API which I think would be very
easy to use (it's mostly a different package).
https://github.com/gnodet/karaf/tree/console-api/shell/console/src/main/java/org/apache/karaf/shell/api
The annotations are basically what we have, the main changes are:
* Action main method has been changed to avoid referencing gogo
* the gogo CommandSession and jline Terminal / ConsoleReder are hidden by
a minimal api (.api.console.Session and Terminal)
* Terminal, Session and BundleContext would be injected with @Reference
along any OSGi service
* bundles containing commands need a Karaf-Command manifest header
The benefits would be the following:
* clean API, so complete separation of command implementors from the
implementation
* also abstract gogo and jline
* no need for blueprint / DS at all
* complete support for what we have
* we could start using semantic versioning on those 3 packages (it
doesn't have to be tied to the release cycle)
* easy enough switch (just a few package changes usually, slightly more
for commands that were using gogo or jline)
* way easier to support a degraded mode on top of pure gogo
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
