karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSS] Where to integrate the new console
Date Wed, 05 Mar 2014 12:30:33 GMT
+1 for shell.core name.


On 03/05/2014 11:51 AM, Guillaume Nodet wrote:
> 2014-03-05 11:07 GMT+01:00 Christian Schneider <chris@die-schneider.net>:
>> 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

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message