2014-03-05 11:07 GMT+01:00 Christian Schneider <[email protected]>:
> The only problem I see is the incompatibility for old modules. > I propose a slightly different layout: > > Leave the old code in shell.console and move the new api and impl > to a new module. Perhaps shell.console2. Not sure about the name. > > So existing users do not have to change anything. For karaf we can easily > move modules to the new dependency. > For outside projects it would be harder. > Yeah, that's definitely a good option. I just need to find a good name for the new one. I don't really like shell.console2 ... What about shell.core ? > > If we manage to keep the compatibility I would like to see this in the 3.1 > branch and remove the old model for 4.0. > > Btw. What do we do for ActiveMQ? Does their style of using the commands > fit into the new api? I guess not. > The ActiveMQ commands do implement CommandWithAction, so they should be fully supported. ActiveMQ could migrate to the new model but that's a different question. > > Christian > > > > > On 05.03.2014 10:48, Guillaume Nodet wrote: > >> I'd like to start a discussion on how and where (in terms of branch / >> version) we can integrate the new console I worked on those past days. >> https://github.com/gnodet/karaf/tree/console-api/ >> >> It provides two apis, one for the console and one for the action model. >> Both apis have no dependencies at all. The action model implementation >> does not depend on the console implementation (only the api) and the >> console implementation does not depend on the action model at all. >> The console implementation is mostly a big refactoring of the current >> console rather than a rewrite bu things are more cleanly separated. The >> action model reuses most of the old code too, but uses an extender and a >> new very light DI system to build the actions. This light DI allows a >> better use outside of OSGi, so that I've been able to have all instance:* >> and ssh:ssh commands to run from bin/shell. >> >> The branch is currently in a very good state: all integration test passes. >> There are still a few things to do (better logs, optimizations), but >> those >> are all very minor. >> >> So now, the question is where to integrate this. The only real (but >> small) >> incompatibility is for external projects at build time: if they don't want >> to migrate to the new action api, they need to depend on the >> org.apache.karaf.shell.compatibility artifact instead of >> org.apache.karaf.shell.console, but that's really the only thing to do. >> >> So I see several options: >> * merge the branch in current master (3.1.x), flag the old console >> interfaces as deprecated and remove support in 4.x >> * create a 4.x branch >> >> In addition, we may want to think about the following things: >> * what to do about the scr support for the old commands in master: this >> is new code, but if we switch the api in 3.1.x, it does not necessarily >> makes sense to support this new code, so better delete it. My first goal >> was to prepare the switch to DS but it's not really needed anymore I think >> * refactor bin/instance and bin/client to use the new non-osgi console >> (or get rid of those) >> * port all commands to the new api >> * consider merging */command and */core into a single bundle as there >> are >> no dependencies on blueprint anymore and we use an extender, using >> optional >> imports for the apis would make sure bundles can start without the console >> and would imho help wrt granularity of our bundles >> >> Thoughts welcomed ! >> >> Cheers, >> Guillaume >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
